Before this patch vdagent-virtio-port was assembling vdagent messages
which consist of multiple chunks without looking at the chunk header port
attribute. But it is possible to receive a vdagent-message which spans
multiple chunks for port 1, and while receiving the chunks for this message,
receive
Don't pass the chunk header, only the chunk port nr, to the read callback,
the size part of the chunk header is irrelavant, esp. as the entire
vdagent message could have been divided over multiple chunks.
---
vdagent-virtio-port.c |2 +-
vdagent-virtio-port.h |2 +-
vdagentd.c|
The chunks being send over the vdagent virtio port are multiplexed and
contain a member inside there header called port, rename all port function
parameters to vport, since they refer to a vdagent-virtio-port, and not a
port in the meaning it has inside of a chunk.
---
vdagent-virtio-port.c | 206
---
vdagent-virtio-port.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/vdagent-virtio-port.c b/vdagent-virtio-port.c
index 961b62c..a4411e5 100644
--- a/vdagent-virtio-port.c
+++ b/vdagent-virtio-port.c
@@ -204,6 +204,9 @@ static void vdagent_virtio_port_do_chunk(stru
Hi All,
While looking into adding support for disabling copy paste to
spice-server, I noticed that spice-server can intermix chunks
from 2 different agent messages, when they come from different
sources (ports in chunk terms, client versus server). The windows
code has an ugly hack to cope with th
On Wed, Mar 23, 2011 at 05:18:50PM +0100, Hans de Goede wrote:
> Some apps (bad xsel, bad!) send invalid Atoms in their TARGETS property,
> causing spicec to exit because of an XError. This patch makes spicec survive
> this scenario.
ACK series.
>
> For more info on the xsel bug, see:
> https://
Although ICCCM 2.2. Responsibilities of the Selection Owner:
http://tronche.com/gui/x/icccm/sec-2.html#s-2.2
Clearly states (about selection notify events):
The owner should set the specified selection, target, time, and property
arguments to the values received in the SelectionRequest event.
xse
Some apps (bad xsel, bad!) send invalid Atoms in their TARGETS property,
causing spicec to exit because of an XError. This patch makes spicec survive
this scenario.
For more info on the xsel bug, see:
https://bugzilla.redhat.com/show_bug.cgi?id=690214
---
client/x11/platform.cpp | 28 ++
Thanks Christophe, applied.
On Tue, Mar 22, 2011 at 3:47 PM, Christophe Fergeau wrote:
> I ran clang static analyzer on gtk-spice using
> scan-build ./autogen.sh && scan-build make -e
> and it reported some errors (unused variables and potential NULL
> dereferences).
> This patch series fixes th
On Wed, Mar 23, 2011 at 01:25:48PM +0200, Alon Levy wrote:
> Way cool. I can't really read the patch there very well. Is this something
> you plan to try pushing into glib?
Here is a more readable version of the same email:
http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00096.html
(b
On Wed, Mar 23, 2011 at 06:03:50PM +0800, Shuxiang Lim wrote:
> Hi,everyone!
>The problems of full glib porting I mentioned in the previous mails have
> been solved, you may reference this:
> http://www.listware.net/201103/gtk-devel-list/55247-full-glib-porting-onto-android.html
Hi,
Way cool
Hi Shuxiang,
On Wed, Mar 23, 2011 at 06:03:50PM +0800, Shuxiang Lim wrote:
>And also after some hacking on spice-gtk(mostly on the SIGBUS/SEGFAULT
> issues,such as replace write_uint16() with memcpy(),..etc),
Are you planning to share these patches? I'm sure spice-gtk maintainers
would be int
Hi,everyone!
The problems of full glib porting I mentioned in the previous mails have
been solved, you may reference this:
http://www.listware.net/201103/gtk-devel-list/55247-full-glib-porting-onto-android.html
And also after some hacking on spice-gtk(mostly on the SIGBUS/SEGFAULT
issues,such
13 matches
Mail list logo
