>
> On Tue, Jan 03, 2017 at 11:00:54AM +, Frediano Ziglio wrote:
> > @@ -618,25 +401,26 @@ static int snd_send_volume(SndChannelClient *client,
> > uint32_t cap, int msg)
> > {
> > SpiceMsgAudioVolume *vol;
> > uint8_t c;
> > -SpiceVolumeState *st = >channel->volume;
> > -
Signed-off-by: Frediano Ziglio
Acked-by: Jonathon Jongsma
---
server/sound.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/server/sound.c b/server/sound.c
index eab6859..20709ba 100644
--- a/server/sound.c
+++ b/server/sound.c
Almost identical beside the type.
Signed-off-by: Frediano Ziglio
Acked-by: Jonathon Jongsma
---
server/sound.c | 53 +++
1 file changed, 16 insertions(+), 37 deletions(-)
diff --git a/server/sound.c
Sound implementation used internal RedChannelClient data while now
it just uses the public interface not thouching RedChannelClient
internal state so now is posible to make this field private.
Signed-off-by: Frediano Ziglio
---
server/red-channel-client-private.h | 11
Signed-off-by: Frediano Ziglio
---
server/Makefile.am| 4 +-
server/dummy-channel-client.c | 138 +---
server/dummy-channel-client.h | 64 +
server/dummy-channel.c| 94 +
Move the freeing of SndChannel data members from snd_detach_common() to
the finalize function to encapsulate things a bit more cleanly. It
doesn't really change the behavior or order of destruction since
snd_detach_common() destroys the channel.
Signed-off-by: Frediano Ziglio
>
> From: Victor Toso
>
> Client might want to choose a preferred video codec for streaming for
> different reasons which having hardware decoder support being the most
> interest one.
>
> This message allows the client to send an array of video codecs in
> order of
>
> Previously, the object we now call SndChannel was named SndWorker, and
> the object we now call SndChannelClient was called SndChannel. When
> these names were changed, the functions
> on_new_(record|playback)_channel() were not updated, so the function
> names and the arguments are both a
These objects were used by the sound channel as
this channel read/write to/from client directly.
This make the code of this channel quite different
from the other ones.
Also this reduce code duplication from RedChannelClient
and increase encapsulation.
Also there are multiple cleanup following
This patch is quite huge but have some benefits:
- reduce dependency (DummyChannel* and some RedChannelClient internals);
- reuse RedChannelClient instead of reading from the RedsStream
directly.
You can see that SndChannelClient has much less field
as the code to read/write from/to client is
We support only a single client so don't waste code just
to check this.
The worst stuff can happen is that we'll migrate multiple
connections.
Signed-off-by: Frediano Ziglio
Acked-by: Jonathon Jongsma
---
server/sound.c | 35
Signed-off-by: Frediano Ziglio
Acked-by: Jonathon Jongsma
---
server/sound.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/server/sound.c b/server/sound.c
index c1bf668..b69b683 100644
--- a/server/sound.c
+++
Signed-off-by: Frediano Ziglio
Acked-by: Jonathon Jongsma
---
server/sound.c | 51 +--
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/server/sound.c b/server/sound.c
index 3feddb9..f6a21a0
red_channel_client_handle_message can handle base messages
so reuse it.
Signed-off-by: Frediano Ziglio
---
server/sound.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/server/sound.c b/server/sound.c
index f6a21a0..c1bf668 100644
---
On Mi, 2017-01-04 at 15:40 +0100, Behrooz Shabani wrote:
> Hi Gerd,
>
>
> I hope you are doing well.
>
>
> I watched one of your talks about virgl and spice, great work!
>
>
> Currently, I am busy with my specialization at Saxion university which
> is about virtualization of graphic cards.
>
Signed-off-by: Frediano Ziglio
---
server/sound.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/server/sound.c b/server/sound.c
index b69b683..76bec77 100644
--- a/server/sound.c
+++ b/server/sound.c
@@ -386,7 +386,6 @@ static int
This allows running big endian and little endian guest side by side using
cut & paste between them.
There is a general design idea that swapping should come as close to
virtio_read/virtio_write as possible. In particular, the protocol
between vdagent and vdagentd is guest-specific and in native
Signed-off-by: Michal Suchanek
---
src/vdagentd/vdagentd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/vdagentd/vdagentd.c b/src/vdagentd/vdagentd.c
index 991514e..60a866e 100644
--- a/src/vdagentd/vdagentd.c
+++ b/src/vdagentd/vdagentd.c
@@ -334,6 +334,7 @@ static
From: Victor Toso
This patch implements a new value to the preference introduced in
497fcbb0a315b034ba keeping it backwards compatible. The new value is
the priority, which is an unsigned integer and should be set as last
argument. e.g: encoder:codec:rank
Video codecs will
From: Victor Toso
Hi,
This is the splitted patch from the thread [0] 'Add preferred video
codec type message'. It basically expands the string parameter from the
public API spice_server_set_video_codecs() to have an optional priority
value -> encoder:video-codec:priority.
From: Victor Toso
* SPICE_MSGC_DISPLAY_PREFERRED_VIDEO_CODEC_TYPE
This message was introduced in protocol 0.12.13 to establish client
side preference on video codec to be used in streams.
At this moment, we only introduce a new API [0] to select *the*
preferred video codec
From: Victor Toso
Client might want to choose a preferred video codec for streaming for
different reasons which having hardware decoder support being the most
interest one.
This message allows the client to send a list of video codecs in a
order of preference.
From: Victor Toso
Similar to preferred video compression, a radio button showing mjpeg,
vp8 and h264 in case server has the proper [0] capability
[0] SPICE_DISPLAY_CAP_PREF_VIDEO_CODEC_TYPE
Signed-off-by: Victor Toso
---
src/spicy.c | 41
From: Victor Toso
Victor Toso (1):
protocol: add preferred video codec message
Signed-off-by: Victor Toso
---
spice-common | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/spice-common b/spice-common
index 86dcd22..2872b15
From: Victor Toso
Small refactor. As reds_get_video_codecs() returns the video codecs as
GArray, we should match reds_set_video_codecs() to have a GArray as
parameter instead of string.
reds_set_video_codecs_from_string() seems more appropriate for the
previous function.
From: Victor Toso
Victor Toso (1):
protocol: add preferred video codec message
Signed-off-by: Victor Toso
---
spice-common | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/spice-common b/spice-common
index 86dcd22..67cea5e
From: Victor Toso
As there is a need to iterate over every encoder:codec pair and we do
a check for every encoder and every codec, g_strsplit() is less
complex and easier to follow.
This change makes much easier to extend the input which is currently a
list of tuples
From: Victor Toso
[0] SPICE_MSGC_DISPLAY_PREFERRED_VIDEO_CODEC_TYPE
This message provides a list of video codecs based on client's order
of preference.
We duplicate the video codecs array from reds.c and sort it using the
order of codecs as reference.
This message will
From: Victor Toso
Hi,
Previous v4 was only one patch reworked (drop sscanf in favour of
g_strsplit). The only change besides that was the removal of the
priority patch as per discussion in the thread [0]. I plan to send it as
a RFC with a better summary, so we can dicuss
From: Victor Toso
Client might want to choose a preferred video codec for streaming for
different reasons which having hardware decoder support being the most
interest one.
This message allows the client to send an array of video codecs in
order of preference.
>
> >
> > From: Victor Toso
> >
> > Victor Toso (1):
> > protocol: add preferred video codec message
> >
> > Signed-off-by: Victor Toso
> > ---
> > spice-common | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
>
> From: Victor Toso
>
> Victor Toso (1):
> protocol: add preferred video codec message
>
> Signed-off-by: Victor Toso
> ---
> spice-common | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/spice-common b/spice-common
From: Victor Toso
Client might want to choose a preferred video codec for streaming for
different reasons which having hardware decoder support being the most
interest one.
This message allows the client to send an array of video codecs in
order of preference.
Hi,
On Fri, Jan 06, 2017 at 04:16:56AM -0500, Frediano Ziglio wrote:
> >
> > From: Victor Toso
> >
> > Client might want to choose a preferred video codec for streaming for
> > different reasons which having hardware decoder support being the most
> > interest one.
> >
>
>
> From: Victor Toso
>
> Client might want to choose a preferred video codec for streaming for
> different reasons which having hardware decoder support being the most
> interest one.
>
> This message allows the client to send an array of video codecs in
> order of
>
> From: Victor Toso
>
> Client might want to choose a preferred video codec for streaming for
> different reasons which having hardware decoder support being the most
> interest one.
>
> This message allows the client to send a list of video codecs in a
> order of
>
> From: Victor Toso
>
> Victor Toso (1):
> protocol: add preferred video codec message
>
> Signed-off-by: Victor Toso
> ---
> spice-common | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/spice-common b/spice-common
37 matches
Mail list logo