On 08/17/2011 06:17 AM, Christophe Fergeau wrote:
Hey,
ACK series, but I haven't read the winfiber code really carefully (since I
know nothing about it).
I compared it with the implementation in QEMU and it seems good.
Paolo
___
Spice-devel mailing
On Wed, Aug 17, 2011 at 7:35 PM, Christophe Fergeau wrote:
> Hey,
Yo,
> These fixes duplicate fixes that already went into master :-/ See commits
> d7d0a3a98e and 0d4bd5504.
Darn! Looks like you did a better job even. :)
--
Regards,
Zeeshan Ali (Khattak)
FSF member#5124
_
On Wed, Aug 17, 2011 at 10:15:01PM +0300, Yonit Halperin wrote:
> On 08/17/2011 09:48 PM, Alon Levy wrote:
> >On Wed, Aug 17, 2011 at 10:19:27AM +0200, David Jaša wrote:
> >>On 17.8.2011 09:47, Yonit Halperin wrote:
> >>>On 08/17/2011 01:54 AM, Marc-André Lureau wrote:
> Hi
>
> I am al
On 08/17/2011 09:48 PM, Alon Levy wrote:
On Wed, Aug 17, 2011 at 10:19:27AM +0200, David Jaša wrote:
On 17.8.2011 09:47, Yonit Halperin wrote:
On 08/17/2011 01:54 AM, Marc-André Lureau wrote:
Hi
I am also unfamiliar with the migration code, in particular the qemu
-> qemu part. It seems to m
On Wed, Aug 17, 2011 at 10:19:27AM +0200, David Jaša wrote:
> On 17.8.2011 09:47, Yonit Halperin wrote:
> > On 08/17/2011 01:54 AM, Marc-André Lureau wrote:
> >> Hi
> >>
> >> I am also unfamiliar with the migration code, in particular the qemu
> >> -> qemu part. It seems to me that no spice transm
On Wed, Aug 17, 2011 at 10:55:53AM -0700, Alon Levy wrote:
> On Wed, Aug 17, 2011 at 12:20:11PM +0200, Christophe Fergeau wrote:
> > Ping?
> >
>
> I'm going to be pushing the multiclient patches, including Yonit's changes
> that kill the Channel struct and reuse RedChannel for that, Any Day Now,
On Wed, Aug 17, 2011 at 01:01:01PM +0200, Christophe Fergeau wrote:
> red_display_marshall_stream_start initializes a
> SpiceMsgDisplayStreamCreate structure before marshalling it and
> sending it on the wire. However, it never fills
> SpiceMsgDisplayStreamCreate::stamp which then causes a complain
On Wed, Aug 17, 2011 at 12:20:11PM +0200, Christophe Fergeau wrote:
> Ping?
>
I'm going to be pushing the multiclient patches, including Yonit's changes
that kill the Channel struct and reuse RedChannel for that, Any Day Now, I
so this will be redundant. (and maybe you'll find a new leak afterwar
Hey,
These fixes duplicate fixes that already went into master :-/ See commits
d7d0a3a98e and 0d4bd5504.
On Wed, Aug 17, 2011 at 05:35:17PM +0300, Zeeshan Ali (Khattak) wrote:
> From: "Zeeshan Ali (Khattak)"
> diff --git a/client/x11/red_window.cpp b/client/x11/red_window.cpp
> index d53a92f..f3
Ack.
On 08/17/2011 03:20 AM, Christophe Fergeau wrote:
Ping?
Christophe
On Tue, Aug 09, 2011 at 07:09:37PM +0200, Christophe Fergeau wrote:
If we don't free it, we'll leak the memory that was allocated in
main_channel_init().
---
server/main_channel.c |1 +
1 files changed, 1 insertion
Yep, sounds good too
Christophe
On Fri, Aug 12, 2011 at 04:50:36PM +0200, Hans de Goede wrote:
> With the filtering of focus in / out events caused by grabs we should no
> longer need this.
>
> Signed-off-by: Hans de Goede
> ---
> gtk/spice-widget-priv.h |2 --
> gtk/spice-widget.c |
Looks good to me, though Marc-André knows this code a lot more than I do :)
Christophe
On Fri, Aug 12, 2011 at 04:50:35PM +0200, Hans de Goede wrote:
> As documented in XGrabKeyboard(3): "The XGrabKeyboard function actively grabs
> control of the keyboard and generates FocusIn and FocusOut events
Looks good, ack from me
Christophe
On Fri, Aug 12, 2011 at 04:50:37PM +0200, Hans de Goede wrote:
> This fixes alt getting stuck in the guest when the user alt-tabs away from the
> spice-widget (thus making it see the alt press but not the release) and then
> closing it without giving it the focu
Looks good to me,
Christophe
On Fri, Aug 12, 2011 at 04:50:34PM +0200, Hans de Goede wrote:
> ---
> gtk/spice-widget-priv.h |1 +
> gtk/spice-widget.c | 36
> gtk/spicy.c |8 +++-
> 3 files changed, 44 insertions(+), 1 deletions
On Fri, Aug 12, 2011 at 04:50:33PM +0200, Hans de Goede wrote:
> diff --git a/gtk/usb-device-manager.c b/gtk/usb-device-manager.c
> new file mode 100644
> index 000..2287383
> --- /dev/null
> +++ b/gtk/usb-device-manager.c
> @@ -0,0 +1,459 @@
> +/* -*- Mode: C; c-basic-offset: 4; indent-tabs-mo
From: "Zeeshan Ali (Khattak)"
---
client/red_channel.cpp|1 +
client/x11/red_window.cpp |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/client/red_channel.cpp b/client/red_channel.cpp
index f4cdf52..ace4a03 100644
--- a/client/red_channel.cpp
+++ b/client/red_cha
Hi,
On Fri, Aug 12, 2011 at 04:50:28PM +0200, Hans de Goede wrote:
> -if (c->xmit_buffer_size) {
> -spice_channel_write(channel, c->xmit_buffer, c->xmit_buffer_size);
> +if (c->xmit_buffer) {
> +/*
> + * Take ownership of the buffer, so that if spice_channel_write c
Hey,
ACK series, but I haven't read the winfiber code really carefully (since I
know nothing about it).
Christophe
On Wed, Aug 17, 2011 at 02:45:11PM +0200, Marc-André Lureau wrote:
> As described in
> http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers
> ---
> gtk/continuation.c
---
data/spicy.nsis.in |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/data/spicy.nsis.in b/data/spicy.nsis.in
index cc9d1b4..4a01a31 100644
--- a/data/spicy.nsis.in
+++ b/data/spicy.nsis.in
@@ -77,7 +77,7 @@ Section "spicy"
File "/usr/i686-w64-mingw32/sys-root/m
---
gtk/spice-widget.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gtk/spice-widget.c b/gtk/spice-widget.c
index a6a0a12..208762e 100644
--- a/gtk/spice-widget.c
+++ b/gtk/spice-widget.c
@@ -867,7 +867,7 @@ static gboolean focus_in_event(GtkWidget *widget,
GdkEventFo
---
gtk/controller/Makefile.am |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/gtk/controller/Makefile.am b/gtk/controller/Makefile.am
index bafad58..4a488e9 100644
--- a/gtk/controller/Makefile.am
+++ b/gtk/controller/Makefile.am
@@ -57,6 +57,13 @@ test_controller_S
---
configure.ac | 40 +++
gtk/Makefile.am | 14 -
gtk/continuation.c|6 +-
gtk/coroutine.h |5 ++
gtk/coroutine_winfibers.c | 120 +
5 files changed, 168 insertions(+), 17 deletions(-
As described in http://www.1024cores.net/home/lock-free-algorithms/tricks/fibers
---
gtk/continuation.c | 12 +++-
gtk/continuation.h |2 ++
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/gtk/continuation.c b/gtk/continuation.c
index 4f5b027..6eaed3c 100644
--- a/gtk
From: Yonit Halperin
Commit 419222f0f3
client: fix endless recursion in rearrange_monitors, RHBZ #692976
introduced a regression: after a resolution change in the guest, it's
no longer possible to start spicec in full screen.
when resizing the screen, the monitors mode (resolution) should be set
From: Marc-André Lureau
After hours of investigation, I am a bit clueless.. It seems XRR is sending
us spurious ScreenChangeNotify in a loop. So we keep calling
init_monitors(), which creates new platform_win etc.. Although none of the
clients seems to be resetting the screen (checked all XRRSet.
---
client/x11/platform.cpp |1 +
client/x11/red_window.cpp | 11 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/client/x11/platform.cpp b/client/x11/platform.cpp
index 1facf73..2adc160 100644
--- a/client/x11/platform.cpp
+++ b/client/x11/platform.cpp
@@ -2958,
---
client/red_channel.cpp | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/client/red_channel.cpp b/client/red_channel.cpp
index f4cdf52..fafb2e1 100644
--- a/client/red_channel.cpp
+++ b/client/red_channel.cpp
@@ -68,10 +68,7 @@ void RedChannelBase::link(uint32_t
Even if VDAgentDisplayConfig::depth will be unused if the
VD_AGENT_DISPLAY_CONFIG_FLAG_SET_COLOR_DEPTH isn't set, it's
better to initialize it anyway to avoid warnings from valgrind.
---
client/red_client.cpp |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/client/red_clien
They were trying to convert the destination pointer to an integer before
trying to dereference it. The initial conversion was meant to be a cast
to a pointer of the right size, not to an integer.
---
common/marshaller.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --
uint63_t should be uint64_t
---
common/marshaller.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/marshaller.c b/common/marshaller.c
index 6ee7b6a..73bee4b 100644
--- a/common/marshaller.c
+++ b/common/marshaller.c
@@ -31,8 +31,8 @@
#define write_uint16(ptr,v)
From: Alon Levy
It was sending the wrong data, the memory right after the VCSMsgHeader
which was actually not where the data was.
Fixed by having the header and data (VSCError, 4 bytes of the error code)
embedded in the ErrorItem pipe item.
---
server/smartcard.c | 30 +++-
Hey,
Since there has been a bunch of bugs fixed recently in master which haven't
been committed to 0.8 as well, I've gone through the recent master commits
and cherry-picked the ones that I thought were useful. I've pushed this
selection to the 0.8 branch of http://cgit.freedesktop.org/~teuf/spice
red_display_marshall_stream_start initializes a
SpiceMsgDisplayStreamCreate structure before marshalling it and
sending it on the wire. However, it never fills
SpiceMsgDisplayStreamCreate::stamp which then causes a complaint
from valgrind. This patch sets this value to 0, it's not used
by the clien
On Tue, Aug 02, 2011 at 01:54:37PM +0300, Alon Levy wrote:
> Good question. I see mm_time is 32 bit, and this is 64. You could pass
> the mm_time here. Is it even used on the other side?
You're right, it doesn't seem to be used in client/
> 0 is still a better value in the meantime :)
Yep, sure
Ping?
Christophe
On Tue, Aug 09, 2011 at 07:09:37PM +0200, Christophe Fergeau wrote:
> If we don't free it, we'll leak the memory that was allocated in
> main_channel_init().
> ---
> server/main_channel.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/server/main_
On Tue, Aug 16, 2011 at 06:54:58PM -0400, Marc-André Lureau wrote:
> > qemu
> > =
> > ui/spice-core::migration_state_notifier should handle MIG_STATE_ACTIVE
> > (for migration start) and MIG_STATE_ERROR/CANCELLED by calling
> > spice_server_migrate_start, and spice_server_migrate_end,
> > respe
Hey Liang,
On Wed, Aug 17, 2011 at 10:14:05AM +0800, Liang Guo wrote:
> $ git clone http://gitorious.org/spice-gtk/spice-gtk
> Cloning into spice-gtk...
> fatal: http://gitorious.org/spice-gtk/spice-gtk/info/refs not found: did you
> run git update-server-info on the server?
>
> checkout spice-g
On 17.8.2011 09:47, Yonit Halperin wrote:
> On 08/17/2011 01:54 AM, Marc-André Lureau wrote:
>> Hi
>>
>> I am also unfamiliar with the migration code, in particular the qemu
>> -> qemu part. It seems to me that no spice transmission occurs, but
>> only guest memory. Is that correct? How is state o
On 08/17/2011 01:54 AM, Marc-André Lureau wrote:
Hi
I am also unfamiliar with the migration code, in particular the qemu -> qemu
part. It seems to me that no spice transmission occurs, but only guest memory. Is
that correct? How is state of the channel restored? Perhaps it doesn't need any
s
On 08/16/2011 06:53 PM, Christophe Fergeau wrote:
Hey Yonit,
I've carefully read the bug report and your email, and looked a bit at the
code, but I'm totally unfamiliar with migration stuff :-/ Your plan sounds
good to me, hopefully changing the client the way you describe won't be too
hard. I h
40 matches
Mail list logo
