>> - Mensagem original -
>> De: "Pavel Grunt"
>> Para: "Thiago Nascimento Araujo" , "Jonathon Jongsma"
>>
>> Cc: spice-devel@lists.freedesktop.org
>> Enviadas: Sexta-feira, 3 de março de 2017 6:20:13
>> Assunto: Re: [Spice-devel] How to send a custom resolution message to
>> windows/lin
Acked-by: Jonathon Jongsma
On Fri, 2017-03-03 at 14:57 +, Frediano Ziglio wrote:
> Sound code is not using Qxl interface.
>
> Signed-off-by: Frediano Ziglio
> ---
> server/sound.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/server/sound.c b/server/sound.c
> index 2e614f0..0f7
I like to see that dependency removed.
Acked-by: Jonathon Jongsma
On Fri, 2017-03-03 at 16:45 +, Frediano Ziglio wrote:
> As the counters are shared there is no reason why not
> handling the byte count from RedChannelClient directly.
> This remove a dependency and avoid some function calls.
Acked-by: Jonathon Jongsma
On Fri, 2017-03-03 at 16:45 +, Frediano Ziglio wrote:
> Show messages sent to clients.
> This is useful to understand the message number as an high
> message number can affects performance and is not easy to
> understand the message count from the byte count (which
On Fri, 2017-03-03 at 14:46 +, Frediano Ziglio wrote:
> This prepare for the next patch.
> As network buffer should be specific to the specific
> RedChannelClient we should have one.
This second sentence is unclear to me. Alternate log suggestion:
"The network recieve buffer should be per-cli
Hi,
After some research, I have been able to install a newer version from:
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.133-1/
Now, Video has experienced a nice improvement... but sound still "hangs"...
Is there any advice to customize sound?
T
Hi
- Original Message -
> This allows us to inform the clients of this library if it was built
> with support for folder sharing or not.
>
> Signed-off-by: Eduardo Lima (Etrunko)
Interesting approach, but you should rather do that at run time. This would
allow to dynamically replace th
On Fri, 2017-03-03 at 14:46 +, Frediano Ziglio wrote:
> These vfuncs are more appropriate in RedChannelClient.
> The buffer they allocated are related to the client stream
> which is managed directly by RedChannelClient.
>
> Signed-off-by: Frediano Ziglio
> ---
> Looking at the patch (mostly
On Fri, 2017-03-03 at 20:19 +0100, Oscar Segarra wrote:
> I must say the version is weird.
> It is the version that comes with 2K8. I have not been able to find
> the W10 qxl driver... ¿Can you paste the link?
>
It is on our page
https://www.spice-space.org/download.html#windows-binaries
Windows
I must say the version is weird.
It is the version that comes with 2K8. I have not been able to find the W10
qxl driver... ¿Can you paste the link?
Beside that which versions (kvm, spice) are you using? Are you using a
recent viewer?
qemu-kvm.x86_6410:1.5.3-126.el7
@base
qemu-kv
This allows us to inform the clients of this library if it was built
with support for folder sharing or not.
Signed-off-by: Eduardo Lima (Etrunko)
---
configure.ac| 1 +
spice-client-glib-2.0.pc.in | 2 ++
2 files changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
> Hi,
> In my environment I have a W10 guest running on a centos 7 KVM host.
> I have installed the following QXL Video driver:
> But when I try to see (on LAN) a youtube video, it doesn't play smoothly,
> even video and sound stops for a while and continues a little bit later. It
> looks I can
Hi,
A new release of the SPICE Guest Tools for Windows is available at
https://www.spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-0.132/spice-guest-tools-0.132.exe
The SPICE Guest Tools for Windows are an all-in-one installer which will
install the virtio drivers, the QXL dr
For the series,
Acked-by: Christophe Fergeau
On Fri, Mar 03, 2017 at 02:21:20PM +, Frediano Ziglio wrote:
> Extract some common code and put in a single file.
> Improve rhel6 compatibility.
>
> Changes since v1:
> - put header stuff in a new file;
> - similar way to exclude some deprecation
Show messages sent to clients.
This is useful to understand the message number as an high
message number can affects performance and is not easy to
understand the message count from the byte count (which is
available).
Signed-off-by: Frediano Ziglio
---
server/red-channel-client.c | 9 +
As the counters are shared there is no reason why not
handling the byte count from RedChannelClient directly.
This remove a dependency and avoid some function calls.
The only visible difference at user level is that the
counters are created when a client connects.
Signed-off-by: Frediano Ziglio
-
Ack,
Pavel
(there are many places where the value can be saved and used)
On Fri, 2017-03-03 at 15:05 +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/dcc.c | 4 ++--
> server/main-channel-client.c | 4 ++--
> server/main-channel.c| 2 +-
> 3
Now the push is done automatically when a PipeItem is added,
forcing a push cause only network fragmentation and is required
only of you are handling data in a loop instead of using the
default loop.
Signed-off-by: Frediano Ziglio
---
server/dcc.c | 2 --
1 file changed, 2 deletions(-)
diff --g
Signed-off-by: Frediano Ziglio
---
server/dcc.c | 4 ++--
server/main-channel-client.c | 4 ++--
server/main-channel.c| 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/server/dcc.c b/server/dcc.c
index 898e074..f42cac0 100644
--- a/server/dcc.c
+++ b/s
Sound code is not using Qxl interface.
Signed-off-by: Frediano Ziglio
---
server/sound.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/server/sound.c b/server/sound.c
index 2e614f0..0f78a67 100644
--- a/server/sound.c
+++ b/server/sound.c
@@ -33,7 +33,6 @@
#include "red-common.h"
#include
These vfuncs are more appropriate in RedChannelClient.
The buffer they allocated are related to the client stream
which is managed directly by RedChannelClient.
Signed-off-by: Frediano Ziglio
---
Looking at the patch (mostly spicevmc.c) looks not great as
you have to have a new class but I think
These vfuncs are dealing with client stream which is a responsibility
of RedChannelClient.
Changes since v1:
- rebased on master.
Frediano Ziglio (2):
Introduce CommonGraphicsChannelClient
red-channel: Move alloc_recv_buf and release_recv_buf to
RedChannelClient
server/common-graphics-c
This prepare for the next patch.
As network buffer should be specific to the specific
RedChannelClient we should have one.
Signed-off-by: Frediano Ziglio
---
server/common-graphics-channel.c | 12
server/common-graphics-channel.h | 32
server/cursor-
Extract some common code and put in a single file.
Improve rhel6 compatibility.
Changes since v1:
- put header stuff in a new file;
- similar way to exclude some deprecation warning.
Frediano Ziglio (3):
tests: Move some glib compatibility code to a separate file
tests: Move some specific GLi
Instead of disabling the code use the compatibility functions.
Signed-off-by: Frediano Ziglio
---
server/tests/Makefile.am | 1 +
server/tests/test-codecs-parsing.c | 7 ---
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/server/tests/Makefile.am b/server/tests/Makefi
Allow to reuse this code in other tests.
Signed-off-by: Frediano Ziglio
---
server/tests/Makefile.am| 2 +
server/tests/test-glib-compat.c | 112
server/tests/test-glib-compat.h | 34
server/tests/test-vdagent.c | 92 +
Signed-off-by: Frediano Ziglio
---
server/tests/test-codecs-parsing.c | 6 +-
server/tests/test-glib-compat.h| 8
server/tests/test-leaks.c | 7 +--
server/tests/test-options.c| 7 +--
server/tests/test-stat-file.c | 10 +-
5 files change
>
> On Thu, Mar 02, 2017 at 01:50:01PM +, Frediano Ziglio wrote:
> > Allow to reuse this code in other tests.
> >
> > Signed-off-by: Frediano Ziglio
> > ---
> > server/glib-compat.h| 9
> > server/tests/Makefile.am| 1 +
> > server/tests/test-glib-compat.c | 112
> On 3 Mar 2017, at 13:10, Marc-André Lureau wrote:
>
> Hi
>
> - Original Message -
>>>
>>> Hi
>>>
>>> - Original Message -
These 2 patches attempt to join images split by RHEL7 graphic
stack (Mesa) decreasing commands handled by spice-server.
You can see
> On 3 Mar 2017, at 13:17, Frediano Ziglio wrote:
>
>>
>> We have recently discussed the use of the bool type. What about sized int
>> types? What is the policy here?
>>
>> Notably, on a part of the code I’m presently working on, I saw that
>> surface_id could be either an int or an uint32_t.
On Fri, Mar 03, 2017 at 07:35:51AM -0500, Frediano Ziglio wrote:
> >
> > On Tue, Feb 28, 2017 at 12:26:41PM -0500, Frediano Ziglio wrote:
> > > >
> > > > On Tue, 2017-02-28 at 09:29 -0500, Frediano Ziglio wrote:
> > > > > >
> > > > > > Related:
> > > > > > https://bugzilla.redhat.com/show_bug.cg
>
> On Tue, Feb 28, 2017 at 12:26:41PM -0500, Frediano Ziglio wrote:
> > >
> > > On Tue, 2017-02-28 at 09:29 -0500, Frediano Ziglio wrote:
> > > > >
> > > > > Related:
> > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1373725
> > > > > ---
> > > > > spice/vd_agent.h | 3 +++
> > > > > 1 fil
>
> We have recently discussed the use of the bool type. What about sized int
> types? What is the policy here?
>
> Notably, on a part of the code I’m presently working on, I saw that
> surface_id could be either an int or an uint32_t. There is apparently no
> clear winner:
>
> $ git grep "int.*
Hi
- Original Message -
> >
> > Hi
> >
> > - Original Message -
> > > These 2 patches attempt to join images split by RHEL7 graphic
> > > stack (Mesa) decreasing commands handled by spice-server.
> > >
> > > You can see the difference between the 2 video:
> > > - https://www.you
> On 3 Mar 2017, at 12:46, Frediano Ziglio wrote:
>
> Due to the way RHEL7 works the images came out from guest using multiple
> commands. This increase the commands to the client and cause the
> video code to create and handle multiple streams creating some
> visual glitches.
> This patch attem
>
> Hi
>
> - Original Message -
> > These 2 patches attempt to join images split by RHEL7 graphic
> > stack (Mesa) decreasing commands handled by spice-server.
> >
> > You can see the difference between the 2 video:
> > - https://www.youtube.com/watch?v=OarV6zUmUdg (before)
> > - https:/
We have recently discussed the use of the bool type. What about sized int
types? What is the policy here?
Notably, on a part of the code I’m presently working on, I saw that surface_id
could be either an int or an uint32_t. There is apparently no clear winner:
$ git grep "int.*surface_id" | wc
Hi
- Original Message -
> These 2 patches attempt to join images split by RHEL7 graphic
> stack (Mesa) decreasing commands handled by spice-server.
>
> You can see the difference between the 2 video:
> - https://www.youtube.com/watch?v=OarV6zUmUdg (before)
> - https://www.youtube.com/watc
Due to the way RHEL7 works the images came out from guest using multiple
commands. This increase the commands to the client and cause the
video code to create and handle multiple streams creating some
visual glitches.
This patch attempt to detect and join the multiple commands to
avoid these issues
The previous patch join correctly the commands however if there
are no more commands the command joined is delayed till new
commands arrive. This patch introduce a timeout (currently 10 ms)
after the command is executed.
Signed-off-by: Frediano Ziglio
---
server/display-channel-private.h | 7 ++
These 2 patches attempt to join images split by RHEL7 graphic
stack (Mesa) decreasing commands handled by spice-server.
You can see the difference between the 2 video:
- https://www.youtube.com/watch?v=OarV6zUmUdg (before)
- https://www.youtube.com/watch?v=5fTdCCbFeCg (after)
These video are reali
>
> On Thu, 2017-03-02 at 11:34 +, Frediano Ziglio wrote:
> > Due to the way RHEL7 works the images came out from guest using
> > multiple
> > commands. This increase the commands to the client and cause the
> > video code to create and handle multiple streams creating some
> > visual glitches
Hi Snir,
Regarding compression and another topic recently evoked, endianness, I wonder
if encoding using LEB128 had been discussed?
LEB128 encodes any value below 128 as 1 bytes, any value below ~16000 as 2
bytes, and so on. It is size and endianness independent. This means that we can
extend
>
> On Thu, 2 Mar 2017, Frediano Ziglio wrote:
> [...]
> > Before I forgot this.
> >
> > Looks like GStreamer when you call gst_buffer_add_video_meta_full
> > assume that buffer is contiguous. The 8 pixel shift (more or less)
> > you can see are artifacts due to how the guest send the frames but
This reverts commit c3d237075b994fe67e58f2b3164cb579e6f4.
When you call gst_buffer_add_video_meta_full GStreamer assumes
that buffer is contiguous. This results usually in some pixels
shift in the video. The pixels shift you can see are artifacts
due to how the guest send the frames but basica
>
> On Thu, Mar 02, 2017 at 05:00:14PM +, Frediano Ziglio wrote:
> > This reverts commit c3d237075b994fe67e58f2b3164cb579e6f4.
>
> I would add an explanation about what is broken (ie a copy and paste of
> what you said in your email about this, link to a gstreamer bug if you
> filed one,
>
> Hey,
>
> Do you have any measurements of how much bandwidth is saved on each
> channel type on basic usage of linux/windows guests? Ideally, with
> numbers about additional CPU usage and added latency?
>
> Christophe
>
Yes, without numbers it's a bit hard understand if worst or not.
> On
On Thu, Mar 02, 2017 at 05:00:14PM +, Frediano Ziglio wrote:
> This reverts commit c3d237075b994fe67e58f2b3164cb579e6f4.
I would add an explanation about what is broken (ie a copy and paste of
what you said in your email about this, link to a gstreamer bug if you
filed one, ..), otherwise
Hey,
Do you have any measurements of how much bandwidth is saved on each
channel type on basic usage of linux/windows guests? Ideally, with
numbers about additional CPU usage and added latency?
Christophe
On Thu, Mar 02, 2017 at 06:53:23PM +0200, Snir Sheriber wrote:
> This series of patches all
On Thu, 2017-03-02 at 13:00 -0300, Thiago Nascimento Araujo wrote:
> Hi,
>
> First of all, thank you all for the quick answers.
>
> The cut off message was my fault, sorry about that.
>
> I am trying to understand this:
>
> Lets say I am connected to a win/lnx guest though remote-viewer and
> m
50 matches
Mail list logo
