We don't want to maintain more macros than necessary and in the end
the equivalent G_GNUC_XXX macros should be preferred.
Should any project actually depend on these macros they can keep using
them by defining the usual SPICE_DEPRECATED macro until they migrate
away from them or the macros are rein
Hi,
On Wed, Dec 14, 2016 at 05:07:17PM -0500, Frediano Ziglio wrote:
> >
> > Commit 5907b6cbb5c724f9729da59a644271b4258d122e started to handle
> > Lock/Unlock events from Session at VDAgent. That seemed to work fine
> > but as pointed by Andrei at [0], it does not cover the following
> > situatio
On Wed, 2016-12-14 at 16:03 -0500, Frediano Ziglio wrote:
> >
> >
> > The fill_bits() function marshalls some data by reference. This
> > data is
> > owned by the RedDrawable that is owned by the Drawable that is
> > owned by
> > the RedDrawablePipeItem. Instead of keeping the RedPipeItem alive
>
> Commit 5907b6cbb5c724f9729da59a644271b4258d122e started to handle
> Lock/Unlock events from Session at VDAgent. That seemed to work fine
> but as pointed by Andrei at [0], it does not cover the following
> situation:
>
> > It fails for next test-case:
> >
> > * Connect with RV to VM
> > * Loc
>
> Hi,
>
> On Wed, Dec 14, 2016 at 02:48:45PM -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.
> > >
>
Limit the html files ignored.
Can happen that you are working on some html files on your main
spice-server directory and it's not desirable to ignore them.
Signed-off-by: Frediano Ziglio
---
.gitignore | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Changes since v1:
- remove redundant
Signed-off-by: Frediano Ziglio
---
server/image-encoders.c | 22 ++
1 file changed, 22 insertions(+)
Changes since v3:
- do not use inline for empty function.
diff --git a/server/image-encoders.c b/server/image-encoders.c
index b23cdf0..698a737 100644
--- a/server/image-enco
Hi,
On Wed, Dec 14, 2016 at 02:48:45PM -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.
> >
> > This message allows
>
> The fill_bits() function marshalls some data by reference. This data is
> owned by the RedDrawable that is owned by the Drawable that is owned by
> the RedDrawablePipeItem. Instead of keeping the RedPipeItem alive by
> passing it to red_channel_client_init_send_data(), simply reference the
>
On Wed, 2016-12-14 at 15:27 -0500, Frediano Ziglio wrote:
> >
> >
> > ---
> > server/spicevmc.c | 14 +++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/server/spicevmc.c b/server/spicevmc.c
> > index d6a6ac8..521a540 100644
> > --- a/server/spicevmc.c
> >
>
> ---
> server/spicevmc.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/server/spicevmc.c b/server/spicevmc.c
> index d6a6ac8..521a540 100644
> --- a/server/spicevmc.c
> +++ b/server/spicevmc.c
> @@ -627,6 +627,12 @@ static void
> spicevmc_red_channel
>
> This third argument (and the 'item' member of
> RedChannelClient::priv::send_data) was a somewhat roundabout way to keep
> the RedPipeItem alive until a message is sent, just in case some data
> owned by that pipeitem was added to the marshaller by reference. This
> was a rather confusing mech
>
> Follow C method naming convention.
Acked-by: Frediano Ziglio
> ---
> server/cursor-channel.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/server/cursor-channel.c b/server/cursor-channel.c
> index f245eed..dedee37 100644
> --- a/server/cursor-channel.c
> +
’m new to overt and this has been a rapid learning curve, and come to point
where I need assistance.
The objective of this project is to provide via a igel thin client a seamless
multimedia experience for the end user.
The environment is based upon both host and virtual instance using Centos 7.
>
> 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.
>
> Signed-off-
Hi,
I was looking for some sort of guidance as to where I was going wrong with
the spice protocol requirements. We are currently trying to use SPICE-html5
client to provide remote access to Virtual Machines hosted on a Xen
hypervisor. It would be really helpful if you could provide us some inputs
We don't want to maintain more macros than necessary and in the end
the equivalent G_GNUC_XXX macros should be preferred.
Should any project actually depend on these macros they can keep using
them by defining the usual SPICE_DEPRECATED macro until they migrate
away from them or the macros are rein
On Tue, Dec 13, 2016 at 06:50:02AM +0100, Francois Gouget wrote:
> We don't want to maintain more macros than necessary and in the end
> the equivalent G_GNUC_XXX macros should be preferred.
> Should any project actually depend on these macros they can keep using
> them by defining the usual SPICE
Move all 'out' parameters to the end of the function.
---
server/cursor-channel.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/server/cursor-channel.c b/server/cursor-channel.c
index dedee37..04483af 100644
--- a/server/cursor-channel.c
+++ b/server/cursor-channel.c
---
server/smartcard-channel-client.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/server/smartcard-channel-client.c
b/server/smartcard-channel-client.c
index 347e177..aece01b 100644
--- a/server/smartcard-channel-client.c
+++ b/server/smartcard-channel-clie
This third argument (and the 'item' member of
RedChannelClient::priv::send_data) was a somewhat roundabout way to keep
the RedPipeItem alive until a message is sent, just in case some data
owned by that pipeitem was added to the marshaller by reference. This
was a rather confusing mechanism, howeve
Use spice_marshaller_add_by_ref_full() instead of _add_by_ref() to
handle the referenced data properly rather than passing the pipe item to
red_channel_client_init_send_data() to keep the pipe item alive
indirectly.
---
server/main-channel-client.c | 14 +++---
1 file changed, 11 insertion
Use spice_marshaller_add_by_ref_full() instead of
spice_marshaller_add_by_ref() to allow the marshaller to manage the
lifetime of the referenced data buffer rather than having to manage it
by passing a PipeItem to red_channel_client_init_send_data(). Since the
data is owned by CursorItem (which is
The only time that the pipe item needs to be passed as the third
argument to red_channel_client_init_send_data() is when the pipe item
holds a data buffer that has been added to the marshaller by reference
(spice_marshaller_add_by_ref()) and needs to be kept alive until the
data has been sent. In a
A series of patches refactoring the somewhat-confusing
red_channel_client_init_send_data() function. The third argument to this
function is a RedPipeItem and it was never very obvious when or why we should
pass an item in this parameter. Sometimes callers passed NULL, and sometimes
they passed an i
---
server/spicevmc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/server/spicevmc.c b/server/spicevmc.c
index d6a6ac8..521a540 100644
--- a/server/spicevmc.c
+++ b/server/spicevmc.c
@@ -627,6 +627,12 @@ static void
spicevmc_red_channel_release_msg_rcv_buf(R
---
server/dcc-send.c | 17 -
server/spicevmc.c | 4 ++--
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/server/dcc-send.c b/server/dcc-send.c
index edeea62..db42ab8 100644
--- a/server/dcc-send.c
+++ b/server/dcc-send.c
@@ -1118,7 +1118,7 @@ static void red_marsh
The fill_bits() function marshalls some data by reference. This data is
owned by the RedDrawable that is owned by the Drawable that is owned by
the RedDrawablePipeItem. Instead of keeping the RedPipeItem alive by
passing it to red_channel_client_init_send_data(), simply reference the
Drawable and
Follow C method naming convention.
---
server/cursor-channel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/server/cursor-channel.c b/server/cursor-channel.c
index f245eed..dedee37 100644
--- a/server/cursor-channel.c
+++ b/server/cursor-channel.c
@@ -104,7 +104,7 @@ s
On Wed, Dec 14, 2016 at 04:43:11PM +0100, Michal Suchánek wrote:
> On Wed, 14 Dec 2016 15:32:11 +0100
> Christophe Fergeau wrote:
>
> > Hey,
> >
> > On Mon, Nov 28, 2016 at 03:08:34PM +0100, Michal Suchanek wrote:
> > > This allows running big endian and little endian guest side by side
> > > us
Hi,
On Thu, Dec 08, 2016 at 03:43:22PM +, Frediano Ziglio wrote:
> 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 (befo
On Wed, Dec 14, 2016 at 04:34:07PM +0100, Victor Toso wrote:
> On Wed, Dec 14, 2016 at 02:32:09PM +0100, Christophe Fergeau wrote:
> > On Wed, Dec 14, 2016 at 08:53:49AM +0100, Victor Toso wrote:
> > > Hi,
> > >
> > > You rock. I'll use this as reference for future proposals, many thanks!
> >
> > W
On Wed, 14 Dec 2016 15:32:11 +0100
Christophe Fergeau wrote:
> Hey,
>
> On Mon, Nov 28, 2016 at 03:08:34PM +0100, Michal Suchanek wrote:
> > This allows running big endian and little endian guest side by side
> > using cut&paste between them.
> >
> > There is some general design idea that swapp
On Wed, Dec 14, 2016 at 02:32:09PM +0100, Christophe Fergeau wrote:
> On Wed, Dec 14, 2016 at 08:53:49AM +0100, Victor Toso wrote:
> > Hi,
> >
> > You rock. I'll use this as reference for future proposals, many thanks!
>
> While this is polished, I'd say this patch is not directly related to
> the
Hey,
On Mon, Nov 28, 2016 at 03:08:34PM +0100, Michal Suchanek wrote:
> This allows running big endian and little endian guest side by side using
> cut&paste between them.
>
> There is some general design idea that swapping should come as cloce to
> virtio_read/virtio_write as possible. In partic
On Tue, Dec 13, 2016 at 02:31:51PM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/image-encoders.c | 26 ++
> 1 file changed, 26 insertions(+)
>
> diff --git a/server/image-encoders.c b/server/image-encoders.c
> index b23cdf0..a529968 100644
On Wed, Dec 14, 2016 at 08:53:49AM +0100, Victor Toso wrote:
> Hi,
>
> You rock. I'll use this as reference for future proposals, many thanks!
While this is polished, I'd say this patch is not directly related to
the 'preferred-video-codec' series? Ie we could at first not have a way
for the serv
On Mon, Dec 12, 2016 at 02:09:24PM +, Frediano Ziglio wrote:
> Limit the html files ignored.
> Can happen that you are working on some html files on your main
> spice-server directory and it's not desirable to ignore them.
>
> Signed-off-by: Frediano Ziglio
> ---
> .gitignore | 2 +-
> 1 fil
s/global/top-level/
Acked-by: Christophe Fergeau
On Mon, Dec 12, 2016 at 02:09:23PM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> .gitignore| 1 +
> server/.gitignore | 5 -
> 2 files changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/.gitignore b/.g
Acked-by: Christophe Fergeau
On Mon, Dec 12, 2016 at 02:09:22PM +, Frediano Ziglio wrote:
> This make more obvious which directory they refer
> and potentially avoid ignoring unwanted files.
>
> Signed-off-by: Frediano Ziglio
> ---
> .gitignore| 2 --
> server/.gitignore | 4 +++-
Acked-by: Christophe Fergeau
On Mon, Dec 12, 2016 at 02:09:21PM +, Frediano Ziglio wrote:
> Signed-off-by: Frediano Ziglio
> ---
> server/.gitignore | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/server/.gitignore b/server/.gitignore
> index 2ff8a4e..3b98549 100644
> --- a/ser
From: Victor Toso
In case of errors in sscanf(), we were returning (codecs + n) being n
an uninitialized variable. That should be avoided in any circumstance.
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
co
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.
Signed-off-by: Victor T
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 for client; In a late
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 +
1 file chang
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.
Signed-off-by: Victor Toso
---
s
From: Victor Toso
We should replace the video_codecs GArray only after the parsing of
input is done, otherwise we might lose previous configuration.
Tests were updated to match this situation. Input that fails to
replace video_codecs are considered bad.
Signed-off-by: Victor Toso
---
server/r
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 now be ordered by its
From: Victor Toso
Frediano Ziglio (6):
Start adding protocol file documentation
Start writing some documentation on protocol
Extended protocol documentation
More work on attribute protocol documentation
Fix BNF notation in documentation
Add protocol documentati
From: Victor Toso
Francois Gouget (1):
codegen: Fix compatibility with Python 2.6
Frediano Ziglio (6):
Start adding protocol file documentation
Start writing some documentation on protocol
Extended protocol documentation
More work on attribute protocol documentation
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 not change an ongoing st
From: Victor Toso
Hi,
I tried to send a few patches beforehand to get this series easier to review and
test, that's why it took some time to resend it.
Gladly, v2 had a really good overview/review about this series usefulness and I
do recomend the read at [0] and the response [1].
[0] https://
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.
Signed-off-by: Victor Toso
---
c
Hi,
On 14-12-16 11:51, Christophe Fergeau wrote:
In newer X.org versions, it's no longer supported to modify the set of
FDs passed to a BlockHandler method to get notified when the FD has data
to be read. This was limited anyway as we could only get read events
this way, and had to do our own po
In newer X.org versions, it's no longer supported to modify the set of
FDs passed to a BlockHandler method to get notified when the FD has data
to be read. This was limited anyway as we could only get read events
this way, and had to do our own polling to get notified about socket
writeability.
St
55 matches
Mail list logo
