Hi,
On Fri, Jan 22, 2016 at 12:12:58PM +0800, nlx wrote:
> Hi list
> I don't want to receive the mail from this list, please tell me how
> to un-subscribe the mail?
> Thanks a lot.
Set your email address and press 'Unsubscribe'
http://lists.freedesktop.org/mailman/options/spi
Hi,
I was thinking about it and the assert also checks for us if there are
more instances of SpiceServer. I would postponed these patches till
other global variables are removed/moved to reds.
Pavel
On Thu, 2016-01-21 at 16:16 +, Frediano Ziglio wrote:
> From: Jonathon Jongsma
>
> Rather t
Thanks!
Acked-by: Pavel Grunt
On Thu, 2016-01-21 at 11:25 -0600, Jonathon Jongsma wrote:
> The replay file should start with a header such as
> SPICE_REPLAY 1
>
> Instead of soldiering on if we don't encounter this header, print a
> warning and return NULL. Also exit with a failure if
> spic
Hi,
On Thu, 2016-01-21 at 22:35 +0100, Fabiano Fidêncio wrote:
> As the message showed when the last usbredir channel is taken can be
> a
> bit confusing, let's add a counter of free channels to the widget's
> label.
> In order to add the counter, a new property for SpiceUsbDeviceManager
> was int
Hi list
I don't want to receive the mail from this list, please tell me how
to un-subscribe the mail?
Thanks a lot.
At 2016-01-22 03:57:52, spice-devel-requ...@lists.freedesktop.org wrote:
>Send Spice-devel mailing list submissions to
> spice-devel@lists.freedesk
I like the idea in general. As you said, it does result in more loop executions,
but presumably it does less in each loop iteration, so I'm not sure whether
that's actually a useful stat or not. For example, this patch reduces the
percentage of times that we exceed the max pipe size of the channel
As the message showed when the last usbredir channel is taken can be a
bit confusing, let's add a counter of free channels to the widget's
label.
In order to add the counter, a new property for SpiceUsbDeviceManager
was introduced ("free-channels").
Related: rhbz#1298772
---
src/usb-device-manage
On Thu, Jan 21, 2016 at 8:46 PM, Jonathon Jongsma wrote:
> On Thu, 2016-01-21 at 19:09 +0100, Fabiano Fidêncio wrote:
>> As the message showed when the last usbredir channel is taken can be a
>> bit confusing, let's add a counter of free channels to the widget's
>> label.
>> In order to add the co
On Thu, Jan 21, 2016 at 8:49 PM, Jonathon Jongsma wrote:
> On Thu, 2016-01-21 at 19:09 +0100, Fabiano Fidêncio wrote:
>> The whole code from usb-device-manager is quite a mess as pointed out by
>
> Perhaps you could use a slightly gentler description :)
>
>> Jonathon during the first round of code
On Thu, 2016-01-21 at 19:09 +0100, Fabiano Fidêncio wrote:
> The whole code from usb-device-manager is quite a mess as pointed out by
Perhaps you could use a slightly gentler description :)
> Jonathon during the first round of code review [0].
> Keeping this in mind and knowing that that code nee
On Thu, 2016-01-21 at 19:09 +0100, Fabiano Fidêncio wrote:
> As the message showed when the last usbredir channel is taken can be a
> bit confusing, let's add a counter of free channels to the widget's
> label.
> In order to add the counter, a new property for SpiceUsbDeviceManager
> was introduced
This series tries to solve the issues reported on rhbz#1298772 in the less
intrusive way possible. As mentioned in the commit log of the second patch
and by Jonathon during the review of v1 this part of code needs some love
and a refactoring task is more than appreciated, but I want to get back to
As the message showed when the last usbredir channel is taken can be a
bit confusing, let's add a counter of free channels to the widget's
label.
In order to add the counter, a new property for SpiceUsbDeviceManager
was introduced ("free-channels").
Related: rhbz#1298772
---
src/usb-device-manage
The whole code from usb-device-manager is quite a mess as pointed out by
Jonathon during the first round of code review [0].
Keeping this in mind and knowing that that code needs a refactor, I'm
proposing a simple (and messy) fix that can be backported easily before
actually dig into a code refacto
Hi,
I was able to reproduce it also without the replay utility.
On Thu, 2016-01-21 at 17:20 +0100, Francois Gouget wrote:
> On Thu, 21 Jan 2016, Pavel Grunt wrote:
> [...]
> > With "gstreamer:h264" it hangs after a while and I see a few of:
> > ((null):24420): Spice-Warning **: gstreamer-
> > enc
The replay file should start with a header such as
SPICE_REPLAY 1
Instead of soldiering on if we don't encounter this header, print a
warning and return NULL. Also exit with a failure if spice_replay_new()
returns a NULL object in main.
---
server/red-replay-qxl.c | 3 +++
server/tests/replay.
On Thu, 2016-01-21 at 11:15 -0600, Jonathon Jongsma wrote:
> The replay file should start with a header such as
> SPICE_REPLAY 1
>
> Instead of soldiering on if we don't encounter this header, print a
> warning and return NULL. Also exit with a failure if spice_replay_new()
> returns a NULL obj
The replay file should start with a header such as
SPICE_REPLAY 1
Instead of soldiering on if we don't encounter this header, print a
warning and return NULL. Also exit with a failure if spice_replay_new()
returns a NULL object in main.
---
server/red-replay-qxl.c | 3 +++
server/tests/replay.
On Thu, 2016-01-21 at 11:48 -0500, Frediano Ziglio wrote:
> >
> > The replay file should start with a header such as
> > SPICE_REPLAY 1
> >
> > Instead of soldiering on if we don't encounter this header, print a
> > warning, and also assert that spice_replay_new() returned a non-NULL
> > object
This patch is inspired from a comment after GLib loop.
Basic: why calling red_channel_push and not let the poll loop
detect if sockets are ready to accept data?
After half a day (literally!) of testing I have honestly
no idea if this patch is an improvement or not. Looks like
more or less the sam
>
> The replay file should start with a header such as
> SPICE_REPLAY 1
>
> Instead of soldiering on if we don't encounter this header, print a
> warning, and also assert that spice_replay_new() returned a non-NULL
> object.
> ---
> server/red-replay-qxl.c | 3 +++
> server/tests/replay.c |
On Thu, 21 Jan 2016, Pavel Grunt wrote:
[...]
> With "gstreamer:h264" it hangs after a while and I see a few of:
> ((null):24420): Spice-Warning **: gstreamer-encoder.c:726:map_format:
> The 8 format has not been tested yet
This message indicates that videos in the SPICE_BITMAP_FMT_32BIT format
h
From: Jonathon Jongsma
Move them into the RedsState struct, adjust functions that use these
variables to take a RedsState arg.
---
server/reds-private.h | 5 +
server/reds.c | 27 ---
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/server/red
From: Jonathon Jongsma
Remove another global variable
---
server/reds-private.h | 1 +
server/reds.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/server/reds-private.h b/server/reds-private.h
index 7a3b524..7f1a6df 100644
--- a/server/reds-private.h
+++ b/
From: Jonathon Jongsma
Rename to make function name more consistent
---
server/main-channel.c | 2 +-
server/main-channel.h | 2 +-
server/reds.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/server/main-channel.c b/server/main-channel.c
index 9623224..1f4fcaa 10
From: Jonathon Jongsma
Rather than using global 'reds' variable
---
server/reds.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index f0087a8..84541e4 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3601,13 +3601,11 @@ SPICE_GNUC_VISIBLE
Hi,
> > ... and the server picks one codec which is supported by both client and
> > gstreamer, with the codec priorities being configurable, is that
> > correct? So things keep working if gstreamer happens to have no h264
> > support (due to the patent mess) on either side?
>
> Yes.
[ ... lo
Patches that change to use local 's' argument now renamed the argument
to 'reds' (like global one).
This patchset contain miscellaneous patch mainly addressed to remove some
global state.
Jonathon Jongsma (15):
Change spice_server_set_ticket() to use local 'reds'
spice_server_add_interface: u
From: Jonathon Jongsma
Make the RedsState object own an InputsChannel object rather than
having a global inputs channel. This means changing a lot of
inputs-related API to take an InputsChannel* argument and moving the
keyboard, mouse, and tablet objects into the InputsChannel object.
---
server
From: Jonathon Jongsma
Also change API of reds_has_vdagent() to take RedsState arg. Removes
another global variable.
---
server/inputs-channel.c | 8
server/main-channel.c | 2 +-
server/reds-private.h | 1 +
server/reds.c | 54 -
From: Jonathon Jongsma
---
server/reds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 36354a6..b108cc8 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3327,7 +3327,7 @@ SPICE_GNUC_VISIBLE int
spice_server_remove_interface(SpiceBa
From: Jonathon Jongsma
removing more global variables
---
server/reds-private.h | 1 +
server/reds.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/server/reds-private.h b/server/reds-private.h
index 91d0cd7..6ce02f9 100644
--- a/server/reds-private.h
+++ b/
From: Jonathon Jongsma
Since the mouse mode is now stored in the inputs channel, we were
crashing when somebody was calling this API before the inputs channel
was created.
---
server/inputs-channel.c | 1 +
server/reds.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff -
From: Jonathon Jongsma
Prefer local argument variable over global 'reds' variable
---
server/reds.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 84541e4..5bcdc09 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3194,13 +3194,11 @
From: Jonathon Jongsma
Not global.
---
server/reds-private.h | 1 +
server/reds.c | 8
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/server/reds-private.h b/server/reds-private.h
index 63e856e..75a4f59 100644
--- a/server/reds-private.h
+++ b/server/reds-private
From: Jonathon Jongsma
---
server/display-channel.c | 13 +++--
server/display-channel.h | 3 +--
server/reds-private.h| 2 ++
server/reds.c| 20
server/reds.h| 5 ++---
5 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/s
From: Jonathon Jongsma
Rename function to be more consistent
---
server/inputs-channel.c | 2 +-
server/inputs-channel.h | 2 +-
server/reds.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/server/inputs-channel.c b/server/inputs-channel.c
index 50650b9..a5959c1
From: Jonathon Jongsma
Since this is public API, we can't easily change the signature of the
function to take a RedsState argument, so instead we apply a hack and
store the reds argument inside the device state struct when the
interface is added, and retrieve it for use later when it is removed.
From: Jonathon Jongsma
---
server/reds-private.h | 1 +
server/reds.c | 32 +++-
2 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/server/reds-private.h b/server/reds-private.h
index 4b7bf50..91d0cd7 100644
--- a/server/reds-private.h
+++ b/ser
Hi All,
The new version of UsbDk (1.0.11) was released.
This version introduces general device support improvements.
The latest UsbDk source code available at:
http://cgit.freedesktop.org/spice/win32/usbdk
Latest source tarball is at:
http://www.spice-space.org/download/windows/usbdk/spice-usb
The replay file should start with a header such as
SPICE_REPLAY 1
Instead of soldiering on if we don't encounter this header, print a
warning, and also assert that spice_replay_new() returned a non-NULL
object.
---
server/red-replay-qxl.c | 3 +++
server/tests/replay.c | 1 +
2 files changed,
hmm, I could have sworn I had pulled git master before I sent this email, but
maybe I didn't...
On Thu, 2016-01-21 at 09:10 +0100, Pavel Grunt wrote:
> Hi,
>
> On Wed, 2016-01-20 at 16:55 -0600, Jonathon Jongsma wrote:
> > On Wed, 2016-01-20 at 16:32 +, Frediano Ziglio wrote:
> > > Finally i
>
> Since SpiceCoreInterfaceInternal is a private data structure, we can
> extend it as we see fit without breaking ABI. In particular, adding a
> GMainContext member to it allows us to remove the need for
> the event loop template which is currently included in the
> basic_event_loop.c test file.
>
> They call the functions provided by event_loop_core, but with a NULL
> SpiceCoreInterfaceInternal parameter. It makes more sense to pass
> event_loop_core rather than NULL.
> This will allow to pass the GMainContext to be used through
> SpiceCoreInterfaceInternal rather than through a template
Since SpiceCoreInterfaceInternal is a private data structure, we can
extend it as we see fit without breaking ABI. In particular, adding a
GMainContext member to it allows us to remove the need for
the event loop template which is currently included in the
basic_event_loop.c test file.
---
server/
From: Frediano Ziglio
Use the glib mainloop instead of writing our own. The glib loop is both
cleaner to use and is more extensible. It is also very mature and
reduces the maintenance burden on the spice server.
Signed-off-by: Marc-André Lureau
Signed-off-by: Jonathon Jongsma
Signed-off-by: Fr
They call the functions provided by event_loop_core, but with a NULL
SpiceCoreInterfaceInternal parameter. It makes more sense to pass
event_loop_core rather than NULL.
This will allow to pass the GMainContext to be used through
SpiceCoreInterfaceInternal rather than through a template parameter.
-
---
server/red-worker.c | 29 -
server/red-worker.h | 1 -
2 files changed, 4 insertions(+), 26 deletions(-)
diff --git a/server/red-worker.c b/server/red-worker.c
index 24bb435..f813649 100644
--- a/server/red-worker.c
+++ b/server/red-worker.c
@@ -64,7 +64,6 @@ stru
Hey,
This is a slightly split up version of the RFC I sent earlier which get rid of
the template file which was introduced for the mainloop in favour of a regular
C file.
Since the glib main loop patch hasn't been pushed yet, the red-worker.c changes
can be squashed in to the "worker: use glib m
On Wed, Jan 20, 2016 at 10:15:42AM -0500, Frediano Ziglio wrote:
> > diff --git a/server/tests/Makefile.am b/server/tests/Makefile.am
> > index 6f02c99..000b097 100644
> > --- a/server/tests/Makefile.am
> > +++ b/server/tests/Makefile.am
> > @@ -27,10 +27,15 @@ libtest_a_SOURCES =
>
> On Thu, Jan 21, 2016 at 07:33:11AM -0500, Frediano Ziglio wrote:
> > >
> > > The next commit will introduce a test for log messages. As
> > > libspice-common.la behaviour varies depending on whether
> > > SPICE_DISABLE_ASSERT was defined at compile-time, this test will also
> > > take into ac
On Thu, Jan 21, 2016 at 07:29:59AM -0500, Frediano Ziglio wrote:
> > +/* Make sure GLib default log handler will show the debug
> > messages. Messing with
> > + * environment variables like this is ugly, but this only
> > happens when the legacy
> > + * SPICE_DEB
On Thu, Jan 21, 2016 at 07:33:11AM -0500, Frediano Ziglio wrote:
> >
> > The next commit will introduce a test for log messages. As
> > libspice-common.la behaviour varies depending on whether
> > SPICE_DISABLE_ASSERT was defined at compile-time, this test will also
> > take into account this prep
On Thu, Jan 21, 2016 at 07:35:44AM -0500, Frediano Ziglio wrote:
> >
> > This gives us a baseline of how the SPICE/glib integration is supposed
> > to behave.
> >
> > Everything goes through glib logging facilities, and is impacted by
> > G_MESSAGES_DEBUG/G_DEBUG=fatal-{warnings,criticals}
> >
>
>
> It's redundant with spice_warn_if_fail(), and can even be confusing.
>
> Acked-by: Jonathon Jongsma
Acked-by: Frediano Ziglio
Frediano
> ---
> common/log.h | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/common/log.h b/common/log.h
> index a56105a..0e03f59 100644
> --- a
>
> This gives us a baseline of how the SPICE/glib integration is supposed
> to behave.
>
> Everything goes through glib logging facilities, and is impacted by
> G_MESSAGES_DEBUG/G_DEBUG=fatal-{warnings,criticals}
>
> Messages in the SPICE_LOG_DOMAIN log domain (output either through
> spice_log
>
> The next commit will introduce a test for log messages. As
> libspice-common.la behaviour varies depending on whether
> SPICE_DISABLE_ASSERT was defined at compile-time, this test will also
> take into account this preprocessor define.
> We are more likely to get a consistent build (SPICE_DISA
>
> If header guards are working as expected, there should not be multiple
> definitions of these macros. If they are redefined somewhere else, this
> is a bug we want to fix.
>
> Acked-by: Jonathon Jongsma
> ---
> common/log.h | 26 --
> 1 file changed, 26 deletions(-)
>
> spice-common has been duplicating glib logging methods for a long while.
> Now that spice-common is depending on glib, it's more consistent to use
> glib logging too. However, the code base is still using spice logging
> functions.
> This commit aims to make spice logging go through glib loggi
Hi Francois,
I tried your patches with a small patch for the replay utility.
http://paste.fedoraproject.org/313167/33783291/
I used an old recording of a Win7 guest a tried to replay it:
./spice-server-replay -c "spicy -h localhost -p 6000 2>/tmp/log.txt" -p
6000 /tmp/win7record.spice -S 2 -v "gs
On Thu, 21 Jan 2016, Gerd Hoffmann wrote:
> Hi,
>
> > Changes from v7:
> > * When the client has support for GStreamer video codecs it now
> > checks the presence of each supported codec before advertising support
> > for it.
>
> ... and the server picks one codec which is supported by
On Wed, Jan 20, 2016 at 10:15:42AM -0500, Frediano Ziglio wrote:
> > diff --git a/server/tests/Makefile.am b/server/tests/Makefile.am
> > index 6f02c99..000b097 100644
> > --- a/server/tests/Makefile.am
> > +++ b/server/tests/Makefile.am
> > @@ -27,10 +27,15 @@ libtest_a_SOURCES =
No need to have our own SPICE_STMT_BEGIN/END and SPICE_STRINGIFY
Acked-by: Jonathon Jongsma
---
common/log.h | 67 ++--
1 file changed, 33 insertions(+), 34 deletions(-)
diff --git a/common/log.h b/common/log.h
index d9e6023..1c54b0f 10064
The next commit will introduce a test for log messages. As
libspice-common.la behaviour varies depending on whether
SPICE_DISABLE_ASSERT was defined at compile-time, this test will also
take into account this preprocessor define.
We are more likely to get a consistent build (SPICE_DISABLE_ASSERT be
It's redundant with spice_warn_if_fail(), and can even be confusing.
Acked-by: Jonathon Jongsma
---
common/log.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/common/log.h b/common/log.h
index a56105a..0e03f59 100644
--- a/common/log.h
+++ b/common/log.h
@@ -95,12 +95,6 @@ void spice_
If header guards are working as expected, there should not be multiple
definitions of these macros. If they are redefined somewhere else, this
is a bug we want to fix.
Acked-by: Jonathon Jongsma
---
common/log.h | 26 --
1 file changed, 26 deletions(-)
diff --git a/commo
They can be used in spice-server to replace spice_return_if_fail.
Currently spice_return_if_fail aborts in spice-server, and it's not
always clear whether using a non-aborting g_return_if_fail is acceptable
or not. Having a spice_assert_if_fail alternative makes it clearer that
this is not going to
spice-common has been duplicating glib logging methods for a long while.
Now that spice-common is depending on glib, it's more consistent to use
glib logging too. However, the code base is still using spice logging
functions.
This commit aims to make spice logging go through glib logging system,
wh
This gives us a baseline of how the SPICE/glib integration is supposed
to behave.
Everything goes through glib logging facilities, and is impacted by
G_MESSAGES_DEBUG/G_DEBUG=fatal-{warnings,criticals}
Messages in the SPICE_LOG_DOMAIN log domain (output either through
spice_log() or g_log()) will
Hi,
Here is a new iteration of the glib patch series.
Main changes is a rework of the test case, some of the test
cases were not working as expected as g_test_init() sets all warnings and
criticals as being fatal, which is not what we want to have by default
when a test case tries to test G_DEBUG=
Hi,
> Changes from v7:
> * When the client has support for GStreamer video codecs it now
> checks the presence of each supported codec before advertising support
> for it.
... and the server picks one codec which is supported by both client and
gstreamer, with the codec priorities being
On Fri, Dec 18, 2015 at 11:40:51AM +0100, Christophe Fergeau wrote:
> On Thu, Dec 17, 2015 at 10:43:05PM +0100, Victor Toso wrote:
> > > +/* Checks that g_return_if_fail() does not abort by default */
> > > +static void test_spice_non_fatal_g_return_if_fail(void)
> > > +{
> > > +char *pattern =
On Wed, 2016-01-20 at 10:50 -0500, Frediano Ziglio wrote:
> > From: Jonathon Jongsma
> >
> > Rather than using global 'reds' variable
> > ---
> > server/reds.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/server/reds.c b/server/reds.c
> > index 080c0f6..c
On Wed, 2016-01-20 at 15:43 +, Frediano Ziglio wrote:
> From: Jonathon Jongsma
>
> ---
> server/reds.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/server/reds.c b/server/reds.c
> index 38e4aef..0db2ad5 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@
On Mon, 18 Jan 2016, Francois Gouget wrote:
>
> The source changed so here is the new revision of this patchset.
>
> This patch series adds support for using GStreamer to encode and decode
> the video streams, adding support for VP8 and h264 codecs.
This round has received no comment at all. T
Hi,
On Wed, 2016-01-20 at 16:55 -0600, Jonathon Jongsma wrote:
> On Wed, 2016-01-20 at 16:32 +, Frediano Ziglio wrote:
> > Finally is time to approach again these patches to use GLib loop
> > functions for RedWorker.
> > Patches has been through so many passages that I'm posting as they
> > ar
76 matches
Mail list logo
