<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Il 06/03/2016 13:25, Yury Shvedov ha scritto:<br>
<blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
Hi, Fabio! <br>
I made 3 new commits. First one updates code to work with new
Spice API. Here, as I think, must be Spice version check if for
example in Debian 8 it less than 0.11.<br>
</blockquote>
<br>
Debian 8 have spice-server 0.12.5, debian 7 with backports have
0.12.4, in any case is good added a check in configure for minimum
required version, I did a commit with >=0.11.2 check based on
your api update, from a fast look I didn't saw newer api. Other
optional cases (like lz4) is/will be with define.<br>
Spice compositor differently from rdp one now should support some
stable versions. This I think is good to avoid rdp compositor
problem that make it after some years still unable in some major
distros: <a class="moz-txt-link-freetext" href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775855">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775855</a>
(was blocked by 814676 - update freerdp)<br>
There are other cases that make the maintainer of solid
distributions refractory to support it.<br>
<br>
<blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su" type="cite"> <br>
Second one is regarding your remarks. I hurried too much with
editing your commits. I'm sorry. So I left your logic but in
another stile. I used "int compression" to handle invalid data.
But than found <span class="blob-code-inner">SPICE_IMAGE_COMPRESS_INVALID
value and changed the variable type back to </span><span
class="blob-code-inner"><span class="pl-c1">spice_image_compression_t.
I think this part is OK now, but if you have something to say
or change there, fill free to do it =)<br>
</span></span></blockquote>
<br>
Thanks, seems very good, in wan compression options case is also
better having specific error message on each option.<br>
I did some commits:<br>
<a class="moz-txt-link-freetext" href="https://github.com/Fantu/compositor-spice/commits/test3">https://github.com/Fantu/compositor-spice/commits/test3</a><br>
Can you cherry-pick since after "Add Spice compositor" if are ok for
you.<br>
About the wan compression patch I did it very fast and I only
checked build (success) but I not tested it and is possible that
have error or unexpected cases doing it fast, I'll try to do other
tests now if I have<span id="result_box" class="short_text"
lang="en"><span class="hps"> enough</span> <span class="hps">time</span></span>
but I'm not sure.<br>
<br>
<blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su" type="cite"><span
class="blob-code-inner"><span class="pl-c1"> <br>
Third - I remove some rubbish like dprint from my old code.
But I'm afraid, there still much to do in this sphere. Will be
perfect if you make the revue, but not now - we have more
important things to do.<br>
<br>
For example, next I'm going to read the code of compositor-rdp
much closely to understand how it works. This needed to know
did we miss something.<br>
<br>
The second thing after that - is to render the screen on the
client side. Now whole images composed on the server and sent
fully to the client.<br>
</span></span></blockquote>
<br>
If will be possible do rendering and image "difference" with opengl
(or probably better also with vulkan) I think can be very useful.<br>
Spice developers added recently spice-egl for support rendering of
vm using virgl with 3d but now is only local.<br>
For remote I don't know if there is something in progress.<br>
I thinked about better possibility to solve improve latency/<span
id="result_box" class="short_text" lang="en"><span class="hps">efficiency
doing all directly with opengl or vulkan (with vk should be
possible </span></span><span id="result_box" class="short_text"
lang="en"><span class="hps"><span id="result_box"
class="short_text" lang="en"><span class="hps">better manage</span>
<span class="hps">resources</span></span>) do directly texture
compressed (to avoid </span></span><span id="result_box"
class="short_text" lang="en"><span class="hps"><span
id="result_box" class="" lang="en"><span class="hps">some
software</span> <span class="hps">steps</span> <span
class="hps">in</span> <span class="hps">that I fear</span>
<span class="hps">most</span> <span class="hps">are</span> <span
class="hps">the leading cause of</span> <span class="hps">latency
and</span> <span class="hps">inefficiency</span></span>), I
saw bc7 that seems to have high quality, alpha support and is
mandatory in vulkan but probably still requires too much
bandwidth.<br>
Alternative with streaming with lossy codec like gstreamer
project in development (I already tested in vm) seems too many
greedy of resources and with too many latency.<br>
</span></span>S<span id="result_box" class="" lang="en"><span
class="hps">o I do not know</span> <span class="hps">if my idea</span>
<span class="hps">can be</span> <span class="hps">implemented</span>
<span class="hps">in practice</span> <span class="hps">or is just</span>
<span class="hps">utopia.<br>
I have too little knowledge to better evaluate.<br>
<br>
I suppose start look rdp and trying to improve generic solution
compatible also without hardware acceleration (to keep it usable
for all users/cases) is a good/fast thing to do initially as
what seems you want already do, after we'll think about utopian
things.<br>
Another thing to look interesting is screen sharing plugin now
usable only with rdp, if will be possible add spice support
easy/fast probably will be good but I not looked its code for
now. (I suppose can be very useful for user remote assistance
thing like teamviewer, I suppose that this with spice full
features </span></span><span id="result_box" class="" lang="en"><span
class="hps"><span id="result_box" class="" lang="en"><span
class="hps">will be better that teamviewer and similar</span></span>)<br>
<br>
</span></span>
<blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su" type="cite"><span
class="blob-code-inner"><span class="pl-c1"> <br>
By the way! Thank you again for your help! =)<br>
<br>
P.S. What did you learn about </span></span>vdagent?</blockquote>
<br>
Is very useful (required for mouse client mode, clipboard copy, file
transfert, ecc...)<br>
I saw the difference for example in xen when now pv domUs can't
support it and isĀ <span class="gt-baf-back"><span id="result_box"
class="short_text" lang="en"><span class="hps">remarkable</span></span>.</span><br>
It is already implemented in xspice but with a fast look seems have
xorg specific things.<br>
I didn't <span id="result_box" class="short_text" lang="en"><span
class="hps">investigated</span> <span class="hps">in detail for
now.<br>
<br>
Sorry for my bad english.<br>
</span></span><br>
<blockquote cite="mid:56DC21CE.1070500@lvk.cs.msu.su" type="cite">
<pre class="moz-signature" cols="72">Kind regards
Yury Shvedov</pre>
<div class="moz-cite-prefix">On 03/04/2016 04:29 PM, Fabio Fantoni
wrote:<br>
</div>
<blockquote cite="mid:56D9A9E3.9050607@m2r.biz" type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<br>
Thanks, another thing I saw only now:<br>
"int compression;" I think should return "<span
class="blob-code-inner"><span class="pl-c1">spice_image_compression_t</span>
compression;</span>" for the better definition. If I'm not
wrong (I not remember for sure) without it the default (<span
class="blob-code-inner">compression =
SPICE_IMAGE_COMPRESS_AUTO_GLZ;</span>) will not works
correctly.<br>
Tomorrow I'll probably added other things, if you did/do
something commit it, to avoid risk of waste time on same part.
I'll try to add and test other compression types and basic
authentication. I take a look to add vdagent support fast/easy
from xspice but seems that there are things xorg specific that I
think will be a problem. Probably it will require changes in
upstream "spice/linux/vd_agent" before trying to use it here.<br>
<br>
Sorry for my bad english.<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>