Re: [Spice-devel] [PATCH spice-common] RFC: spice.proto: add webdav channel
On 03/14/2014 06:17 PM, Marc-André Lureau wrote: If no further comments, can I move ahead adding that new channel? ACK by me. On Fri, Feb 28, 2014 at 4:39 PM, David Jaša dj...@redhat.com wrote: On Čt, 2014-02-27 at 18:27 +0100, Marc-André Lureau wrote: Hi On Wed, Feb 26, 2014 at 11:00 PM, Jonathon Jongsma jjong...@redhat.com wrote: There's also the option of using a 'temporary' name (e.g. DraftWebDAVChannel or something) until we're convinced that it's the right approach and then rename it to a more official name and advertise it as stable... Imho, we should prefer versioning over unstable APIs when possible. The fact that channel id X will be named DraftWebDAVChannel or WebDAVChannel doesn't change much, but perhaps it makes it clear that it could be removed/replaced later. Tbh, this is all hypothetical, the proposed implementation works well with both Linux and Windows remotes (but more exposure would help finding shortcomings..) IMO fresh builds in virt-preview repo could bring some extra exposure... David ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Don't truncate large 'now' values in _spice_timer_set
On 03/10/2014 12:58 PM, Christophe Fergeau wrote:
From: David Gibson dgib...@redhat.com
static void _spice_timer_set(SpiceTimer *timer, uint32_t ms, uint32_t now)
The _spice_timer_set() function takes a 32-bit integer for the now value.
The now value passed in however, can exceed 2^32 (it's in ms and derived
from CLOCK_MONOTONIC, which will wrap around a 32-bit integer in around 46
days).
If the now value passed in exceeds 2^32, this will mean timers are inserted
into the active list with expiry values before the current time, they will
immediately trigger, and (if they don't make themselves inactive) be
reinserted still before the current time.
This leads to an infinite loop in spice_timer_queue_cb().
https://bugzilla.redhat.com/show_bug.cgi?id=1072700
ACK
---
server/spice_timer_queue.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/server/spice_timer_queue.c b/server/spice_timer_queue.c
index 8f6e9c8..71de84a 100644
--- a/server/spice_timer_queue.c
+++ b/server/spice_timer_queue.c
@@ -147,7 +147,7 @@ SpiceTimer *spice_timer_queue_add(SpiceTimerFunc func,
void *opaque)
return timer;
}
-static void _spice_timer_set(SpiceTimer *timer, uint32_t ms, uint32_t now)
+static void _spice_timer_set(SpiceTimer *timer, uint32_t ms, uint64_t now)
{
RingItem *next_item;
SpiceTimerQueue *queue;
@@ -183,7 +183,8 @@ void spice_timer_set(SpiceTimer *timer, uint32_t ms)
spice_assert(pthread_equal(timer-queue-thread, pthread_self()) != 0);
clock_gettime(CLOCK_MONOTONIC, now);
-_spice_timer_set(timer, ms, now.tv_sec * 1000 + (now.tv_nsec / 1000 /
1000));
+_spice_timer_set(timer, ms,
+ (uint64_t)now.tv_sec * 1000 + (now.tv_nsec / 1000 /
1000));
}
void spice_timer_cancel(SpiceTimer *timer)
@@ -217,7 +218,7 @@ void spice_timer_remove(SpiceTimer *timer)
unsigned int spice_timer_queue_get_timeout_ms(void)
{
struct timespec now;
-int now_ms;
+int64_t now_ms;
RingItem *head;
SpiceTimer *head_timer;
SpiceTimerQueue *queue = spice_timer_queue_find_with_lock();
@@ -232,9 +233,9 @@ unsigned int spice_timer_queue_get_timeout_ms(void)
head_timer = SPICE_CONTAINEROF(head, SpiceTimer, active_link);
clock_gettime(CLOCK_MONOTONIC, now);
-now_ms = (now.tv_sec * 1000) - (now.tv_nsec / 1000 / 1000);
+now_ms = ((int64_t)now.tv_sec * 1000) - (now.tv_nsec / 1000 / 1000);
-return MAX(0, ((int)head_timer-expiry_time - now_ms));
+return MAX(0, ((int64_t)head_timer-expiry_time - now_ms));
}
@@ -252,7 +253,7 @@ void spice_timer_queue_cb(void)
}
clock_gettime(CLOCK_MONOTONIC, now);
-now_ms = (now.tv_sec * 1000) + (now.tv_nsec / 1000 / 1000);
+now_ms = ((uint64_t)now.tv_sec * 1000) + (now.tv_nsec / 1000 / 1000);
while ((head = ring_get_head(queue-active_timers))) {
SpiceTimer *timer = SPICE_CONTAINEROF(head, SpiceTimer, active_link);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Mouse mode client vs Mouse mode server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/15/2014 06:33 AM, Lindsay Mathieson wrote: Whats the significance of this? does server mode come into play when there is no qxl spice agent in the guest? client/server mode has the client/server determine the location of the cursor and render it. So client mode has better mouse responsiveness, especially with high latency. A spice agent (vdagent) is required for client mode. You can also use a usb tablet in which case you get the same 'perk' but nothing else that the agent provides (unless you run it - you can run both, although it doesn't make sense). With a tablet you also cannot use multiple monitors (the mouse is mapped wrongly). ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTJr6uAAoJEGSFt2Lm6PXuBrsIALC8xR3Hu9owjveGDmM2dUYH /J4r9XCRKh2xM5VdrSdUgvVRLkjzkDkjorSpJBIR+vv3dXbUMNJmH8PP52t7zGed WZwjP8M4Kj9da0rzuMxFbbjoCz9W/ZJ4ylEGsQH6sDODkVVoWWNq8gIWNjxOaJPJ OnsD0bXXQiJH69Ac31sHuHfJLOURmfO72KCDNNpWPeN3uErxVdv5ecPJn92LUYev CfEPRvaJXMWPof9AblEYbfXxaqMdS1zG4d5837paJ/6Pa/932psklrJYUM6uc39W bbbVHoglrI/hFoL1BzbDAi6ezC3DMW3O4ONpYWIst2PtkSXT2zhTsXF7L0badBU= =p7yv -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] migration: Don't assert() if MIGRATE_DATA comes before attaching the agent
On 02/24/2014 07:44 PM, Christophe Fergeau wrote:
During seamless migration, after switching host, if a client was connected
during the migration, it will have data to send back to the new
qemu/spice-server instance. This is handled through MIGRATE_DATA messages.
SPICE char devices use such MIGRATE_DATA messages to restore their state.
However, the MIGRATE_DATA message can arrive any time after the new qemu
instance has started, this can happen before or after the SPICE char
devices have been created. In order to handle this, if the migrate data
arrives early, it's stored in reds-agent_state.mig_data, and
attach_to_red_agent() will restore the agent state as appropriate.
Unfortunately this does not work as expected as expected. If
attach_to_red_agent() is called before the MIGRATE_DATA message reaches the
server, all goes well, but if MIGRATE_DATA reaches the server before
attach_to_red_agent() gets called, then some assert() get triggered in
spice_char_device_state_restore():
((null):32507): Spice-ERROR **:
char_device.c:937:spice_char_device_state_restore: assertion
`dev-num_clients == 1 dev-wait_for_migrate_data' failed
Thread 3 (Thread 0x7f406b543700 (LWP 32543)):
Thread 2 (Thread 0x7f40697ff700 (LWP 32586)):
Thread 1 (Thread 0x7f4079b45a40 (LWP 32507)):
What happens is that dev-wait_for_migrate_data is unconditionally cleared
when
completing handling of the MIGRATE_DATA message, so it's FALSE when
spice_char_device_state_restore() is called. Moreover, dev-num_clients is
also 0 as this is only increased by spice_char_device_start() which
spice_server_char_device_add_interface() calls after
attach_to_red_agent()/spice_char_device_state_restore() have been called.
This commit changes the logic in spice_server_char_device_add_interface(),
and when there is migrate data pending in reds-agent_state.mig_data, we
only attempt to restore it after successfully initializing/starting the
needed char device.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035184
Looks good to me, ack.
---
server/reds.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 1f02553..217c74e 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -2856,16 +2856,7 @@ static SpiceCharDeviceState
*attach_to_red_agent(SpiceCharDeviceInstance *sin)
state-read_filter.discard_all = FALSE;
reds-agent_state.plug_generation++;
-if (reds-agent_state.mig_data) {
-spice_assert(reds-agent_state.plug_generation == 1);
-reds_agent_state_restore(reds-agent_state.mig_data);
-free(reds-agent_state.mig_data);
-reds-agent_state.mig_data = NULL;
-} else if
(!red_channel_waits_for_migrate_data(reds-main_channel-base)) {
-/* we will assoicate the client with the char device, upon
reds_on_main_agent_start,
- * in response to MSGC_AGENT_START */
-main_channel_push_agent_connected(reds-main_channel);
-} else {
+if (red_channel_waits_for_migrate_data(reds-main_channel-base) ||
reds-agent_state.mig_data) {
spice_debug(waiting for migration data);
if (!spice_char_device_client_exists(reds-agent_state.base,
reds_get_client())) {
int client_added;
@@ -2882,9 +2873,13 @@ static SpiceCharDeviceState
*attach_to_red_agent(SpiceCharDeviceInstance *sin)
spice_warning(failed to add client to agent);
reds_disconnect();
}
-
}
+} else {
+/* we will associate the client with the char device, upon
reds_on_main_agent_start,
+ * in response to MSGC_AGENT_START */
+main_channel_push_agent_connected(reds-main_channel);
}
+
return state-base;
}
@@ -2990,6 +2985,15 @@ static int
spice_server_char_device_add_interface(SpiceServer *s,
spice_warning(failed to create device state for %s,
char_device-subtype);
return -1;
}
+
+if (strcmp(char_device-subtype, SUBTYPE_VDAGENT) == 0) {
+if (reds-agent_state.mig_data) {
+ spice_assert(reds-agent_state.plug_generation == 1);
+ reds_agent_state_restore(reds-agent_state.mig_data);
+ free(reds-agent_state.mig_data);
+ reds-agent_state.mig_data = NULL;
+}
+}
return 0;
}
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH server] Associate org.spice-space.webdav.0 port to webdav channel
On 01/12/2014 07:34 PM, Marc-André Lureau wrote:
For example, with qemu, a webdav channel can be created this way:
-chardev spiceport,name=org.spice-space.webdav.0,...
And redirected to a virtio port:
-device virtserialport,...,name=org.spice-space.webdav.0
Ack. Still reviewing the gtk part. I've tested this.
---
server/reds.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/server/reds.c b/server/reds.c
index 2a0002b..2c63154 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3668,7 +3668,11 @@ static int
spice_server_char_device_add_interface(SpiceServer *s,
dev_state = spicevmc_device_connect(char_device,
SPICE_CHANNEL_USBREDIR);
}
else if (strcmp(char_device-subtype, SUBTYPE_PORT) == 0) {
-dev_state = spicevmc_device_connect(char_device, SPICE_CHANNEL_PORT);
+if (strcmp(char_device-portname, org.spice-space.webdav.0) == 0) {
+dev_state = spicevmc_device_connect(char_device,
SPICE_CHANNEL_WEBDAV);
+} else {
+dev_state = spicevmc_device_connect(char_device,
SPICE_CHANNEL_PORT);
+}
}
if (dev_state) {
@@ -4206,6 +4210,7 @@ SPICE_GNUC_VISIBLE int
spice_server_set_channel_security(SpiceServer *s, const c
[ SPICE_CHANNEL_SMARTCARD] = smartcard,
#endif
[ SPICE_CHANNEL_USBREDIR ] = usbredir,
+[ SPICE_CHANNEL_WEBDAV ] = webdav,
};
int i;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [vdagent-win 0/2] Add VD_AGENT_CAP_MAX_CLIPBOARD support
On 03/09/2014 07:01 PM, Uri Lublin wrote: This patch-set adds support for max-clipboard. The implementation is similar to the implementation of linux-vdagent. Patch1 fixes clipboard error handling (also will be used in Patch2) Patch2 implements max-clipboard support Patches look good to me. Uri Lublin (2): vdagent: clipboard: GlobalUnlock on handle_request failure vdagent: clipboard: Add VD_AGENT_CAP_MAX_CLIPBOARD support spice-protocol | 2 +- vdagent/vdagent.cpp | 42 ++ 2 files changed, 39 insertions(+), 5 deletions(-) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk 0/2] WebDAV channel
On 02/28/2014 02:16 PM, Marc-André Lureau wrote: From: Marc-André Lureau marcandre.lur...@redhat.com Hi, This is the client bits to get folder sharing capability using the WebDAV channel. How to test it? You'll need spice-server with this patch: http://patchwork.freedesktop.org/patch/17802/ Then using qemu master, use the following port redirection: -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel1,id=channel1,name=org.spice-space.webdav.0 -chardev spiceport,name=org.spice-space.webdav.0,id=charchannel1 In a Windows guest, you must then install http://elmarco.fedorapeople.org/spice-webdavd-x86-0.1.24.msi, and register the drive (by running map-drive.bat from Program Files/Spice webdav). By default, the public share directory is used. You may specify a different folder with --spice-share-dir option. With a Linux guest, atm, you must compile phodav (form git.gnome.org) and run spice-webdavd -p 8000 as root. The folder will show up in nautilus network places. It can then be mounted and browsed in traditional apps thanks to gvfs-fuse. Tested with fedora and windows 7. With fedora had to use (apparently well known) mounting via connect to server in nautilus, with both had to use spicy since remote-viewer is not yet working (just a note to other people testing this). Works fine in my small testing, no notifications in guest from host changes (well known limitation) but copy/paste worked fine (largest file I copied was 3 Megabyte guest to host). I'll try to review next. Marc-André Lureau (2): Add webdav channel session: add shared-dir property and option .gitmodules | 3 + autogen.sh | 2 +- configure.ac | 4 + doc/reference/spice-gtk-docs.xml | 1 + doc/reference/spice-gtk-sections.txt | 17 + doc/reference/spice-gtk.types| 4 +- gtk/Makefile.am | 9 +- gtk/channel-webdav.c | 737 +++ gtk/channel-webdav.h | 68 gtk/map-file | 1 + gtk/phodav | 1 + gtk/spice-channel.c | 6 + gtk/spice-client.h | 1 + gtk/spice-glib-sym-file | 1 + gtk/spice-option.c | 5 + gtk/spice-session-priv.h | 6 + gtk/spice-session.c | 50 ++- spice-common | 2 +- 18 files changed, 912 insertions(+), 6 deletions(-) create mode 100644 gtk/channel-webdav.c create mode 100644 gtk/channel-webdav.h create mode 16 gtk/phodav ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Kubuntu as a KVM virtualised guest with spice drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/2014 05:30 AM, Lindsay Mathieson wrote: My apologies if this is inappropriate for the list. I run a proxmox cluster at work (kvm/qemu 1.7) and X just restarts constantly when trying to use the guest drivers for spice (QXL, xserver-xorg-video-qxl). I've tested this with 13.04, 13.10 and 14.04 beta. Also the same with vanilla ubuntu. What is the version of xserver-xorg-video-qxl? what is the qemu version? what is the qemu command line? what does lspci -v say in the guest when run as root? what is the X server output? (/var/log/Xorg.0.log assuming :0 is the display id) However Centos, Fedora and Debian run fine, fast and responsive. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTEw4tAAoJEGSFt2Lm6PXuSL8IAKOmbeZ4TCn8HOBIa32g9H0B JJL3hFm0+KbfqI/CvmZk/IbcRvbLNA/QWbxwAfFM7Rdj/zYRGx9W7F/8g5BCrsVg ksZEQQXYxyyXmneDJoQSKSyKvsAch0Hm+oFht9AbFTj3laKdaAKBJrvFGKQhmHoT 7j7RG/h0N0llyqhnTVyTM64b7uKXgztOtJRWQuW/rqAMh3jVQCGWzwLuFg2cF3Ix WJurthmNTEFF5O35g6fuc/fUI986lZSb7pqfq1Sy88dfr/f17izcf7IdwqmOUsQJ d70QHedQU9ARZI9tlV5p5KN6BO+6ctaLS61x/AloKyXzE1X2eHQtp8wITeB+UAs= =yvOp -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] How to start with Spice Development?
On 02/17/2014 08:14 PM, Jeremy White wrote: On 02/17/2014 08:44 AM, Alf G. wrote: Hi, I am very interested to delve into spice and perhaps do some work on it. What is the best way to start? Can I use the documents on spice-space.org/documentation.html http://spice-space.org/documentation.html as base or are they not at all up to date? Is the spice-project written in pure C or also are there C++ parts? That's great, and welcome! I think the documentation is pretty out of date. It's certainly a good start, and the core concepts in the protocol haven't changed, but the web site is well behind the code. The code is mostly C; there is a (deprecated) client written in C++. There is also a Javascript web client. I'd recommend that your first action is to pick an interesting use case, and get it working with code from git. So either qemu + windows guest, or qemu + linux guest, or pure Xspice. From there, it gets trickier. I don't think we have a set of 'easy' projects to start with. The links on the devel page don't take you to a list of open bugs, but this link should work: https://bugs.freedesktop.org/buglist.cgi?query_format=specificorder=relevance%20descbug_status=__open__product=Spice Welcome! This link is for the freedesktop bugs, but there are also a considerable number of bugs on the Red Hat bugtracker: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDclassification=Fedoracomponent=spicecomponent=spice-gtkcomponent=virt-viewercomponent=spice-html5component=spice-parentcomponent=spice-protocolcomponent=spice-vdagentcomponent=spice-xpicomponent=xorg-x11-drv-qxllist_id=2259049product=Fedoraquery_format=advanced That is incomplete - qemu is not in there, but it includes many unrelated bugs. Most Spice developers work for Red Hat, and they have internal bug trackers as well that track their priorities. But I have found them to be quite friendly and welcoming. They're often helpful on the #spice channel on irc as well. Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Building Spice in an IDE
On 02/01/2014 12:54 AM, Wade Johnson wrote: Hi, I am trying to build Spice in Eclipse and make a test environment, but I am having some issues mostly with some dependencies not being resolved, and some constant definitions not being found. Are there any pointers or build guides to getting Spice set up in Eclipse that you guys have? I haven't tried doing that. If you are building spice-server you need to do git submodule init; git submodule update and you need to install some dependencies - pixman mainly, opus. In summary, if you post a specific error message it would help. The wiki has the development instructions here: http://www.spice-space.org/page/Building_Instructions (pointed to from main page via http://www.spice-space.org/page/DeveloperStartPage) Thanks, Wade Johnson ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Qemu-devel] [PULL 0/1 v2] libcacard glusterfs fix
changes from v1: Added Signed-of by me. The following changes since commit 1f6b12f75f2c22f861d0202374033a7594c91707: Merge remote-tracking branch 'remotes/mwalle/tags/lm32-fixes/20140204' into staging (2014-02-08 15:57:51 +) are available in the git repository at: git://people.freedesktop.org/~alon/qemu pull-libcacard.glusterfs for you to fetch changes up to 73db416ae7941f8ffeabc060ec87402b97314b6d: libcacard: Don't link with all libraries QEMU links to (2014-02-09 13:06:02 +0200) Christophe Fergeau (1): libcacard: Don't link with all libraries QEMU links to libcacard/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.5.3
[Qemu-devel] [PULL 1/1] libcacard: Don't link with all libraries QEMU links to
From: Christophe Fergeau cferg...@redhat.com As described in https://bugzilla.redhat.com/show_bug.cgi?id=987441 , libcacard currently links to all the libraries QEMU is linking to, including glusterfs libraries, libiscsi, ... libcacard does not need all of these. This patch ensures it's only linked with the libraries it needs. Signed-off-by: Christophe Fergeau cferg...@redhat.com Signed-off-by: Alon Levy al...@redhat.com --- libcacard/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libcacard/Makefile b/libcacard/Makefile index 4d15da4..6b06448 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -25,7 +25,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ -export-syms $(SRC_PATH)/libcacard/libcacard.syms -libcacard.la: LIBS += $(libcacard_libs) +libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^) -- 1.8.5.3
Re: [Qemu-devel] [PATCH] libcacard: Don't link with all libraries QEMU links to
On 01/30/2014 03:56 PM, Christophe Fergeau wrote: Acked-by: Alon Levy al...@redhat.com As described in https://bugzilla.redhat.com/show_bug.cgi?id=987441 , libcacard currently links to all the libraries QEMU is linking to, including glusterfs libraries, libiscsi, ... libcacard does not need all of these. This patch ensures it's only linked with the libraries it needs. Signed-off-by: Christophe Fergeau cferg...@redhat.com --- libcacard/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libcacard/Makefile b/libcacard/Makefile index 4d15da4..6b06448 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -25,7 +25,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ -export-syms $(SRC_PATH)/libcacard/libcacard.syms -libcacard.la: LIBS += $(libcacard_libs) +libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^)
[Qemu-devel] [PULL 1/1] libcacard: Don't link with all libraries QEMU links to
From: Christophe Fergeau cferg...@redhat.com As described in https://bugzilla.redhat.com/show_bug.cgi?id=987441 , libcacard currently links to all the libraries QEMU is linking to, including glusterfs libraries, libiscsi, ... libcacard does not need all of these. This patch ensures it's only linked with the libraries it needs. Signed-off-by: Christophe Fergeau cferg...@redhat.com --- libcacard/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libcacard/Makefile b/libcacard/Makefile index 4d15da4..6b06448 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -25,7 +25,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ -export-syms $(SRC_PATH)/libcacard/libcacard.syms -libcacard.la: LIBS += $(libcacard_libs) +libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^) -- 1.8.4.2
[Qemu-devel] [PULL 0/1] libcacard glusterfs fix
The following changes since commit 0706f7c85b3c0783f92d44b551f362884db0f4bd: Merge remote-tracking branch 'mjt/tags/trivial-patches-2014-01-16' into staging (2014-01-30 13:56:00 +) are available in the git repository at: git://people.freedesktop.org/~alon/qemu pull-libcacard.glusterfs for you to fetch changes up to 02c783d9d356f3e6410e46fc3f96114024e3fc32: libcacard: Don't link with all libraries QEMU links to (2014-01-30 16:54:06 +0200) Christophe Fergeau (1): libcacard: Don't link with all libraries QEMU links to libcacard/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.8.4.2
[Spice-devel] [PATCH] Handle SIGUSR1 from and SIGHUP to X
From: Anonymous wishes@to.remain Relevant excerpt from Xserver(1) man page: /SIGUSR1/ This signal is used quite differently from either of the above. When the server starts, it checks to see if it has inherited SIGUSR1 as SIG_IGN instead of the usual SIG_DFL. In this case, the server sends a SIGUSR1 to its parent process after it has set up the various connection schemes. /Xdm/ uses this feature to recognize when connecting to the server is possible. With this patch KDM works correctly when launching Xspice instead of Xorg. Problem reported and patch provided by anonymous. --- scripts/Xspice | 45 - 1 file changed, 40 insertions(+), 5 deletions(-) diff --git a/scripts/Xspice b/scripts/Xspice index b8a7b78..d2b2b81 100755 --- a/scripts/Xspice +++ b/scripts/Xspice @@ -22,7 +22,7 @@ import sys import tempfile import atexit import time -import signal +from signal import getsignal, signal, SIGTERM, SIGUSR1, SIGHUP from subprocess import Popen, PIPE def which(x): @@ -178,7 +178,12 @@ def launch(*args, **kw): cleanup_processes.append(p) return p -signal.signal(signal.SIGTERM, cleanup) +# Save signal values to reset them when starting X +saved_sigterm = getsignal(SIGTERM) +saved_sighup = getsignal(SIGHUP) +saved_sigusr1 = getsignal(SIGUSR1) + +signal(SIGTERM, cleanup) atexit.register(cleanup) if args.auto: @@ -279,7 +284,35 @@ if args.vdagent_enabled: if os.path.exists(f): os.unlink(f) cleanup_files.extend([args.vdagent_virtio_path, args.vdagent_uinput_path]) -xorg = launch(executable=args.xorg, args=exec_args + xorg_args) + +# X gives special meaning to SIGUSR1 and SIGHUP (SIGTERM is already handled) +xorg = None + +# SIGUSR1 needs to propagate to parent +def sigusr1(*args): +os.kill(os.getppid(), SIGUSR1) + +# SIGHUP needs to propagate to X +def sighup(*args): +if xorg is None: +return +# xorg.pid might not be valid anymore when a signal arrives after +# xorg.wait() returns, but the script did not yet exit +try: +os.kill(xorg.pid, SIGHUP) +except Exception: +pass + +def reset_handlers(): +signal(SIGTERM, saved_sigterm) +signal(SIGHUP, saved_sighup) +signal(SIGUSR1, saved_sigusr1) + +signal(SIGUSR1, sigusr1) +signal(SIGHUP, sighup) + +# use preexec_fn to reset the signal handlers for the X process back to the original values +xorg = launch(executable=args.xorg, args=exec_args + xorg_args, preexec_fn=reset_handlers) time.sleep(2) retpid,rc = os.waitpid(xorg.pid, os.WNOHANG) @@ -289,11 +322,13 @@ else: if args.vdagent_enabled and args.vdagent_launch: # XXX use systemd --user for this? vdagentd = launch(args=[args.vdagentd_exec, '-x', '-S', vdagentd_uds, - '-s', args.vdagent_virtio_path, '-u', args.vdagent_uinput_path]) + '-s', args.vdagent_virtio_path, '-u', args.vdagent_uinput_path], + preexec_fn=reset_handlers) time.sleep(1) # TODO wait for uinput pipe open for write vdagent = launch(args=[args.vdagent_exec, '-x', '-s', args.vdagent_virtio_path, '-S', - vdagentd_uds]) + vdagentd_uds], + preexec_fn=reset_handlers) if args.xsession: environ = os.environ os.spawnlpe(os.P_NOWAIT, args.xsession, environ) -- 1.8.4.2 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Users] [Spice-devel] Windows guest
On 01/19/2014 11:40 PM, Maurice James wrote: Is it on the roadmap? There is ongoing work to get a WDDM driver, and there is work to get 3d local rendering that is unrelated but useful to spice, virgl. Once those two are done then we can talk about direct3d. -Original Message- From: Alon Levy [mailto:al...@redhat.com] Sent: Sunday, January 19, 2014 9:06 AM To: Itamar Heim; Maurice James; users@ovirt.org; spice-devel Subject: Re: [Spice-devel] [Users] Windows guest On 01/18/2014 12:36 AM, Itamar Heim wrote: On 01/16/2014 04:22 PM, Maurice James wrote: Does anyone know if directdraw/directx works on windows guests in Ovirt? adding spice devel There is no direct3d or directdraw implementation in the driver we provide. ___ Spice-devel mailing list spice-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Spice-devel] [Users] Windows guest
On 01/19/2014 11:40 PM, Maurice James wrote: Is it on the roadmap? There is ongoing work to get a WDDM driver, and there is work to get 3d local rendering that is unrelated but useful to spice, virgl. Once those two are done then we can talk about direct3d. -Original Message- From: Alon Levy [mailto:al...@redhat.com] Sent: Sunday, January 19, 2014 9:06 AM To: Itamar Heim; Maurice James; us...@ovirt.org; spice-devel Subject: Re: [Spice-devel] [Users] Windows guest On 01/18/2014 12:36 AM, Itamar Heim wrote: On 01/16/2014 04:22 PM, Maurice James wrote: Does anyone know if directdraw/directx works on windows guests in Ovirt? adding spice devel There is no direct3d or directdraw implementation in the driver we provide. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] randr: Make resolution changing more robust
On 01/20/2014 06:43 PM, Christophe Fergeau wrote:
When running a guest using a KMS QXL driver on a RHEL6 hypervisor,
spice_vdagent would crash on resolution changes with:
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x0
Serial number of failed request: 75
Current serial number in output stream: 75
(if using a newer QEMU, this will not crash as the resolution codepath is
totally different, see red_dispatcher_use_client_monitors_config() in
spice-server, when using the UMS QXL driver, the crash will not happen
because of
http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=907d0ff0
).
This crash happens in vdagent_x11_set_monitor_config() because the X server
rejects the request because we are trying to set a CRTC to a size which is
bigger than the current screen (using 'screen' and 'CRTC' as in the RandR
spec at http://www.x.org/releases/X11R7.5/doc/randrproto/randrproto.txt ).
If we resize the screen before changing the CRTCs resolution, then this
error will no longer happen. However, if we first call XRRSetScreenSize()
and then XRRSetCrtcConfig(), the call to XRRSetScreeSize() will fail when
we try to make the screen smaller as there will be active CRTCs which would
be bigger than the screen.
In order to solve these issues, we follow the same process as what mutter
does in meta_monitor_manager_xrandr_apply_configuration()
https://git.gnome.org/browse/mutter/tree/src/core/monitor-xrandr.c#n689:
1. we disable the CRTCs which are off and the ones which are bigger than the
size we want to set the screen to.
2. we resize the screen with a call to XRRSetScreenSize().
3. we set each CRTCs to their new resolution.
ACK with two lines removed, see below.
---
src/vdagent-x11-randr.c | 61
++---
1 file changed, 48 insertions(+), 13 deletions(-)
diff --git a/src/vdagent-x11-randr.c b/src/vdagent-x11-randr.c
index 5223f88..77b2127 100644
--- a/src/vdagent-x11-randr.c
+++ b/src/vdagent-x11-randr.c
@@ -688,8 +688,6 @@ void vdagent_x11_set_monitor_config(struct vdagent_x11
*x11,
VDAgentMonitorsConfig *mon_config,
int fallback)
{
-int width, height;
-int x, y;
int primary_w, primary_h;
int i, real_num_of_monitors = 0;
VDAgentMonitorsConfig *curr = NULL;
@@ -748,24 +746,40 @@ void vdagent_x11_set_monitor_config(struct vdagent_x11
*x11,
for (i = mon_config-num_of_monitors; i x11-randr.res-noutput; i++)
xrandr_disable_output(x11, i);
+/* First, disable disabled CRTCs... */
for (i = 0; i mon_config-num_of_monitors; ++i) {
if (!monitor_enabled(mon_config-monitors[i])) {
xrandr_disable_output(x11, i);
continue;
You can drop this continue now.
}
-/* Try to create the requested resolution */
-width = mon_config-monitors[i].width;
-height = mon_config-monitors[i].height;
-x = mon_config-monitors[i].x;
-y = mon_config-monitors[i].y;
-if (!xrandr_add_and_set(x11, i, x, y, width, height)
-enabled_monitors(mon_config) == 1) {
-set_screen_to_best_size(x11, width, height,
-primary_w, primary_h);
-goto update;
+}
+
+/* ... and disable the ones that would be bigger than
+ * the new RandR screen once it is resized. If they are enabled the
+ * XRRSetScreenSize call will fail with BadMatch. They will be
+ * reenabled after hanging the screen size.
+ */
+for (i = 0; i curr-num_of_monitors; ++i) {
+int width, height;
+int x, y;
+
+width = curr-monitors[i].width;
+height = curr-monitors[i].height;
+x = curr-monitors[i].x;
+y = curr-monitors[i].y;
+
+if ((x + width primary_w) || (y + height primary_h)) {
+if (x11-debug)
+syslog(LOG_DEBUG, Disabling monitor %d:
+ (%d+%d, %d+%d) (%d,%d),
+ i, x, width, y, height, primary_w, primary_h);
+
+xrandr_disable_output(x11, i);
+continue;
Also here.
}
}
+/* Then we can resize the RandR screen. */
if (primary_w != x11-width[0] || primary_h != x11-height[0]) {
if (x11-debug)
syslog(LOG_DEBUG, Changing screen size to %dx%d,
@@ -793,7 +807,28 @@ void vdagent_x11_set_monitor_config(struct vdagent_x11
*x11,
}
}
-update:
+/* Finally, we set the new resolutions on RandR CRTCs now that the
+ * RandR screen is big enough to hold these. */
+for (i = 0; i mon_config-num_of_monitors; ++i) {
+int width,
[Qemu-devel] [PATCH 1/2] hw/display/qxl: improve framebuffer error message
Signed-off-by: Alon Levy al...@redhat.com
---
hw/display/qxl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index e4f172e..f6af470 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -1367,7 +1367,8 @@ static void qxl_create_guest_primary(PCIQXLDevice *qxl,
int loadvm,
size = abs(requested_stride) * requested_height;
if (size qxl-vgamem_size) {
qxl_set_guest_bug(qxl, %s: requested primary larger then framebuffer
-size, __func__);
+size %d %d, __func__, size,
+ qxl-vgamem_size);
return;
}
--
1.8.4.2
[Qemu-devel] [PATCH 2/2] qxl: clear irq on reset
Without this we occasionally trigger an assert at hw/pci/pci.c:pcibus_reset that asserts the irq_count is zero on reset. This has become a problem with the new drm driver for linux, since doing a reboot from console causes a race between console updates that set the irq and the reset assertion that the irq is clear. Signed-off-by: Alon Levy al...@redhat.com --- hw/display/qxl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/display/qxl.c b/hw/display/qxl.c index f6af470..e164d96 100644 --- a/hw/display/qxl.c +++ b/hw/display/qxl.c @@ -1126,6 +1126,7 @@ static void qxl_reset_state(PCIQXLDevice *d) d-num_free_res = 0; d-last_release = NULL; memset(d-ssd.dirty, 0, sizeof(d-ssd.dirty)); +qxl_update_irq(d); } static void qxl_soft_reset(PCIQXLDevice *d) -- 1.8.4.2
[Qemu-devel] [PATCH v2] hw/display/qxl: fix signed to unsigned comparison
Fix signed to unsigned comparison in qxl_create_guest_primary and add
the size of the framebuffer to the error message used when setting the
guest bug state (which causes a complete guess blackout until reset, so
it helps if it is verbose).
Signed-off-by: Alon Levy al...@redhat.com
---
hw/display/qxl.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index e4f172e..b799b51 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -1360,14 +1360,15 @@ static void qxl_create_guest_primary(PCIQXLDevice *qxl,
int loadvm,
{
QXLDevSurfaceCreate surface;
QXLSurfaceCreate *sc = qxl-guest_primary.surface;
-int size;
+uint32_t size;
int requested_height = le32_to_cpu(sc-height);
int requested_stride = le32_to_cpu(sc-stride);
size = abs(requested_stride) * requested_height;
if (size qxl-vgamem_size) {
-qxl_set_guest_bug(qxl, %s: requested primary larger then framebuffer
-size, __func__);
+qxl_set_guest_bug(qxl, %s: requested primary larger than framebuffer
+size %u %u, __func__, size,
+ qxl-vgamem_size);
return;
}
--
1.8.4.2
[Qemu-devel] [PATCH v3] hw/display/qxl: fix signed to unsigned comparison
Several small signedness / overflow corrections to qxl_create_guest_primary:
1. use 64 bit unsigned for size to avoid overflow possible from two 32
bit multiplicants.
2. correct sign for requested_height
3. add a more verbose error message when setting guest bug state (which
causes a complete guess blackout until reset, so it helps if it is
verbose).
Signed-off-by: Alon Levy al...@redhat.com
---
hw/display/qxl.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index e4f172e..ba752b5 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -1360,14 +1360,15 @@ static void qxl_create_guest_primary(PCIQXLDevice *qxl,
int loadvm,
{
QXLDevSurfaceCreate surface;
QXLSurfaceCreate *sc = qxl-guest_primary.surface;
-int size;
-int requested_height = le32_to_cpu(sc-height);
+uint64_t size;
+uint32_t requested_height = le32_to_cpu(sc-height);
int requested_stride = le32_to_cpu(sc-stride);
size = abs(requested_stride) * requested_height;
if (size qxl-vgamem_size) {
-qxl_set_guest_bug(qxl, %s: requested primary larger then framebuffer
-size, __func__);
+qxl_set_guest_bug(qxl, %s: requested primary larger than framebuffer
+size % PRIu64 % PRIu32, __func__, size,
+ qxl-vgamem_size);
return;
}
--
1.8.4.2
[Qemu-devel] [PATCH v4] hw/display/qxl: fix signed to unsigned comparison
Several small signedness / overflow corrections to qxl_create_guest_primary:
1. use 64 bit unsigned for size to avoid overflow possible from two 32
bit multiplicants.
2. correct sign for requested_height
3. add a more verbose error message when setting guest bug state (which
causes a complete guess blackout until reset, so it helps if it is
verbose).
Signed-off-by: Alon Levy al...@redhat.com
---
hw/display/qxl.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index e4f172e..ceae1d9 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -19,6 +19,7 @@
*/
#include zlib.h
+#include stdint.h
#include qemu-common.h
#include qemu/timer.h
@@ -1360,14 +1361,16 @@ static void qxl_create_guest_primary(PCIQXLDevice *qxl,
int loadvm,
{
QXLDevSurfaceCreate surface;
QXLSurfaceCreate *sc = qxl-guest_primary.surface;
-int size;
-int requested_height = le32_to_cpu(sc-height);
+uint32_t requested_height = le32_to_cpu(sc-height);
int requested_stride = le32_to_cpu(sc-stride);
-size = abs(requested_stride) * requested_height;
-if (size qxl-vgamem_size) {
-qxl_set_guest_bug(qxl, %s: requested primary larger then framebuffer
-size, __func__);
+if (requested_stride == INT32_MIN ||
+abs(requested_stride) * (uint64_t)requested_height
+ qxl-vgamem_size) {
+qxl_set_guest_bug(qxl, %s: requested primary larger than framebuffer
+stride %d x height % PRIu32 % PRIu32,
+ __func__, requested_stride, requested_height,
+ qxl-vgamem_size);
return;
}
--
1.8.4.2
Re: [Users] [Spice-devel] Windows guest
On 01/18/2014 12:36 AM, Itamar Heim wrote: On 01/16/2014 04:22 PM, Maurice James wrote: Does anyone know if directdraw/directx works on windows guests in Ovirt? adding spice devel There is no direct3d or directdraw implementation in the driver we provide. ___ Spice-devel mailing list spice-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Spice-devel] Meeting at FOSDEM'14
On 01/17/2014 10:24 PM, Fedor Lyakhov wrote: Hi, Who is going to visit FOSDEM this year? It would be nice to meet you there! I'll be giving a talk https://fosdem.org/2014/schedule/event/virtiaas23/ on Sunday (Feb 2nd) in the Virtualisation dev room, and you're very welcome! I am going to FOSDEM, so is Hans although he is no longer actively working on spice. I will plan to attend your talk. Media redirection for Spice remote computing solution Project Melange: optimizing media stream processing for media players and VoIP clients in virtual desktop infrastructures. This is cross-functional project involving technologies of virtualization (Spice), multimedia and VoIP (GStreamer, Google WebRTC, others in future), remote services (Apache Thrift, D-Bus). I and my friends Egor M. and Alexey K. have started this project Melange, it is currently hosted at https://github.com/lyakhov/melange and is in the very early stage of development - we're preparing 2 prototypes for the FOSDEM. There are many architectural and design questions I'd like to discuss - to determine the best way of reaching Melange's goals... Me and Egor (Alexey couldn't make it unfortunately) will arrive to Brussels slightly earlier - so we'll get to FOSDEM Beer Event in Delirium at 31st evening, hope to meet you there! (https://fosdem.org/2014/practical/beerevent/) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Users] Windows guest
On 01/18/2014 12:36 AM, Itamar Heim wrote: On 01/16/2014 04:22 PM, Maurice James wrote: Does anyone know if directdraw/directx works on windows guests in Ovirt? adding spice devel There is no direct3d or directdraw implementation in the driver we provide. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 00/17] Split RedsStream out of reds.c
On 01/07/2014 01:14 PM, Christophe Fergeau wrote: Hey, This is a series I've had locally for a while. It moves RedsStream related code out of reds.c to its own file. This shaves ~1000 lines of code out of reds.c The patch series could be split in 2 independent series, first one would be patches 1-8 which is code movements from reds.c to redsstream.c. Second part would be patch 9-17 were I move some RedsStream fields from being public (exposed in a .h file) to being private (only available in redsstream.c). There are still a few public fields in RedsStream after this series, but I haven't addressed them yet. In particular, it would be nice to hide the 'socket' member behind accessors so that we have a clear idea of what the rest of spice-server code can/cannot do with this socket. At the moment, various part of spice-server directly call setsockopt or things like this on it. Ack series. Just address my one comment on patch 16. Christophe ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 03/17] Move sync_write* to reds_stream.h
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/13/2014 01:00 PM, Christophe Fergeau wrote: On Sun, Jan 12, 2014 at 01:04:10PM +0200, Alon Levy wrote: On 01/07/2014 01:14 PM, Christophe Fergeau wrote: They are renamed to reds_stream_write* You also changed the return type for reds_stream_write_all (was sync_write) to bool, which is now being cast to int in some code paths. Which code path do you mean? The code paths in this patch are either ignoring reds_stream_write_* return values or using it as a boolean (with ! or ). Christophe My bad, I missed the boolean and in reds_send_link_error, it does cast the bool to int (the logical and of two red_stream_write_all calls) but that is not an error. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS09TPAAoJEGSFt2Lm6PXueBYH/j7jXbn9oexh4kmRz4RhC1w7 91Ij34Z+S34moZq6MRHsk4nwICwiTC0EhMtOF2qz50ubH0yMUMxXMrNVwkRdiwuc AzFbTZ+6hEOvL72kqecOUTnzUaou4UKicmBDgAtYAvx8K57hjzUZGdtc6fl5UjWq 2m7Buvx8hWKAM7inwwl33tC7wYSjYkQvedIoH3qLGAiORqAr9IvfP2/0HBFENfTR nONr4lhWx+pIW1LtsbiVpAi8FOKbnuDW1K/gU7sVyXkLkWqpAejeN3uICTpXoczg plwYgMUIEInKrtYAbu3Ju9+BhfMKaKOAM+Gaq+zcBa/kdp0iT8VFT0s5ISpmLsk= =ZRoW -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 3/3] Add VD_AGENT_CAP_MAX_CLIPBOARD support
On 01/07/2014 01:28 AM, Marc-André Lureau wrote:
ping
Looks good to me.
On Thu, Nov 14, 2013 at 5:03 PM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
Do not send clipboard data bigger than last received
VDAgentMaxClipboard.
There is no need to further limit at the session agent, since it is
already OOM safe, and since marhsalling/sending is local, that shouldn't
make any stability or speed difference that deserves the added
complexity.
---
src/vdagentd.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/vdagentd.c b/src/vdagentd.c
index 2eb97cb..1098fb6 100644
--- a/src/vdagentd.c
+++ b/src/vdagentd.c
@@ -74,6 +74,7 @@ static int agent_owns_clipboard[256] = { 0, };
static int quit = 0;
static int retval = 0;
static int client_connected = 0;
+static int max_clipboard = -1;
/* utility functions */
/* vdagentd - spice-client communication handling */
@@ -98,6 +99,7 @@ static void send_capabilities(struct vdagent_virtio_port
*vport,
VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_CLIPBOARD_SELECTION);
VD_AGENT_SET_CAPABILITY(caps-caps,
VD_AGENT_CAP_SPARSE_MONITORS_CONFIG);
VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_GUEST_LINEEND_LF);
+VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_MAX_CLIPBOARD);
vdagent_virtio_port_write(vport, VDP_CLIENT_PORT,
VD_AGENT_ANNOUNCE_CAPABILITIES, 0,
@@ -369,6 +371,13 @@ int virtio_port_read_complete(
vdagent_virtio_port_reset(vport, VDP_CLIENT_PORT);
do_client_disconnect();
break;
+case VD_AGENT_MAX_CLIPBOARD:
+if (message_header-size != sizeof(VDAgentMaxClipboard))
+goto size_error;
+VDAgentMaxClipboard *msg = (VDAgentMaxClipboard *)data;
+syslog(LOG_DEBUG, Set max clipboard: %d, msg-max);
+max_clipboard = msg-max;
+break;
default:
syslog(LOG_WARNING, unknown message type %d, ignoring,
message_header-type);
@@ -453,6 +462,12 @@ int do_agent_clipboard(struct udscs_connection *conn,
case VDAGENTD_CLIPBOARD_DATA:
msg_type = VD_AGENT_CLIPBOARD;
data_type = header-arg2;
+if (max_clipboard != -1 size max_clipboard) {
+syslog(LOG_WARNING, clipboard is too large (%d %d),
discarding,
+ size, max_clipboard);
+virtio_write_clipboard(selection, msg_type, data_type, NULL, 0);
+return 0;
+}
break;
case VDAGENTD_CLIPBOARD_RELEASE:
msg_type = VD_AGENT_CLIPBOARD_RELEASE;
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fw: Re: multiple client connect spice-server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2014 01:10 PM, Lindsay Mathieson wrote: On Tue, 7 Jan 2014 10:38:26 AM David Ja?a wrote: No, only one client can connect at the same time. David On Út, 2014-01-07 at 10:05 +0800, hhb584520 wrote: how to multiple spice clients can connect to spice server at one time? It can be done: http://www.spice-space.org/page/Features/MultipleClients That page clearly says it is not recommended for anything but testing, it is broken by design and needs more work, I would only recommend it for someone who plans to develop it further. Worked for me, but haven't heavily tested it. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS0nJtAAoJEGSFt2Lm6PXuDS8H/1+XycKEKm0EyqoN/DkXTkTy AxstQmNV8t8CEhI0fBUy3A6WutkB/Zie+trAKDECYG4zoR8y4PhZ90iKoNOBXsTK H9wi/9ug4Bvc5B6wfTiMpz8GafwyZ/i86o1b0KlxM53YpDUc+GUUz72D+DoJWJQ5 UTaqdiWkklqsWbqe2UQUWft1Fdi95ZSX1gUS7xaS/NcICu2O03++vGjV1ZPNv8G+ d6sLjprApJG5w9OJU+ABJRv+XmWA1tBYlRQKpPED+XSg6uiIsGwKtD1x6CQWGQYt sBzGnewr+2zz3dpm53AwOA9DJXCt4+pufrfADiH+y3N44SMY85lwolE6t+eTpAI= =CQ2L -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 03/17] Move sync_write* to reds_stream.h
On 01/07/2014 01:14 PM, Christophe Fergeau wrote:
They are renamed to reds_stream_write*
You also changed the return type for reds_stream_write_all (was
sync_write) to bool, which is now being cast to int in some code paths.
Not an objection, but perhaps worth a later patch (unless it's already
addressed, I'm commenting while reading so haven't read the later
patches yet).
---
server/reds.c| 78
server/reds_stream.c | 28 +++
server/reds_stream.h | 5
3 files changed, 57 insertions(+), 54 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 81e90f3..ce8bb97 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1395,24 +1395,6 @@ int reds_handle_migrate_data(MainChannelClient *mcc,
SpiceMigrateDataMain *mig_d
return TRUE;
}
-static int sync_write(RedsStream *stream, const void *in_buf, size_t n)
-{
-const uint8_t *buf = (uint8_t *)in_buf;
-
-while (n) {
-int now = reds_stream_write(stream, buf, n);
-if (now = 0) {
-if (now == -1 (errno == EINTR || errno == EAGAIN)) {
-continue;
-}
-return FALSE;
-}
-n -= now;
-buf += now;
-}
-return TRUE;
-}
-
static void reds_channel_init_auth_caps(RedLinkInfo *link, RedChannel
*channel)
{
if (sasl_enabled !link-skip_auth) {
@@ -1473,13 +1455,13 @@ static int reds_send_link_ack(RedLinkInfo *link)
BIO_get_mem_ptr(bio, bmBuf);
memcpy(ack.pub_key, bmBuf-data, sizeof(ack.pub_key));
-if (!sync_write(link-stream, header, sizeof(header)))
+if (!reds_stream_write_all(link-stream, header, sizeof(header)))
goto end;
-if (!sync_write(link-stream, ack, sizeof(ack)))
+if (!reds_stream_write_all(link-stream, ack, sizeof(ack)))
goto end;
-if (!sync_write(link-stream, channel_caps-common_caps,
channel_caps-num_common_caps * sizeof(uint32_t)))
+if (!reds_stream_write_all(link-stream, channel_caps-common_caps,
channel_caps-num_common_caps * sizeof(uint32_t)))
goto end;
-if (!sync_write(link-stream, channel_caps-caps, channel_caps-num_caps
* sizeof(uint32_t)))
+if (!reds_stream_write_all(link-stream, channel_caps-caps,
channel_caps-num_caps * sizeof(uint32_t)))
goto end;
ret = TRUE;
@@ -1500,7 +1482,7 @@ static int reds_send_link_error(RedLinkInfo *link,
uint32_t error)
header.minor_version = SPICE_VERSION_MINOR;
memset(reply, 0, sizeof(reply));
reply.error = error;
-return sync_write(link-stream, header, sizeof(header))
sync_write(link-stream, reply,
+return reds_stream_write_all(link-stream, header, sizeof(header))
reds_stream_write_all(link-stream, reply,
sizeof(reply));
}
@@ -1522,7 +1504,7 @@ static void reds_info_new_channel(RedLinkInfo *link,
int connection_id)
static void reds_send_link_result(RedLinkInfo *link, uint32_t error)
{
-sync_write(link-stream, error, sizeof(error));
+reds_stream_write_all(link-stream, error, sizeof(error));
}
int reds_expects_link_id(uint32_t connection_id)
@@ -1977,18 +1959,6 @@ static inline void async_read_clear_handlers(AsyncRead
*obj)
reds_stream_remove_watch(obj-stream);
}
-#if HAVE_SASL
-static int sync_write_u8(RedsStream *s, uint8_t n)
-{
-return sync_write(s, n, sizeof(uint8_t));
-}
-
-static int sync_write_u32(RedsStream *s, uint32_t n)
-{
-return sync_write(s, n, sizeof(uint32_t));
-}
-#endif
-
static void async_read_handler(int fd, int event, void *data)
{
AsyncRead *obj = (AsyncRead *)data;
@@ -2157,14 +2127,14 @@ static void reds_handle_auth_sasl_step(void *opaque)
if (serveroutlen) {
serveroutlen += 1;
-sync_write(link-stream, serveroutlen, sizeof(uint32_t));
-sync_write(link-stream, serverout, serveroutlen);
+reds_stream_write_all(link-stream, serveroutlen, sizeof(uint32_t));
+reds_stream_write_all(link-stream, serverout, serveroutlen);
} else {
-sync_write(link-stream, serveroutlen, sizeof(uint32_t));
+reds_stream_write_all(link-stream, serveroutlen, sizeof(uint32_t));
}
/* Whether auth is complete */
-sync_write_u8(link-stream, err == SASL_CONTINUE ? 0 : 1);
+reds_stream_write_u8(link-stream, err == SASL_CONTINUE ? 0 : 1);
if (err == SASL_CONTINUE) {
spice_info(%s, Authentication must continue (step));
@@ -2182,7 +2152,7 @@ static void reds_handle_auth_sasl_step(void *opaque)
}
spice_info(Authentication successful);
-sync_write_u32(link-stream, SPICE_LINK_ERR_OK); /* Accept auth */
+reds_stream_write_u32(link-stream, SPICE_LINK_ERR_OK); /* Accept
auth */
/*
* Delay writing in SSF encoded until
Re: [Spice-devel] [PATCH 16/17] Introduce reds_stream_set_channel()
On 01/07/2014 01:14 PM, Christophe Fergeau wrote:
---
server/reds.c| 6 +++---
server/reds_stream.c | 9 +
server/reds_stream.h | 2 ++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index a993f2c..c6983d8 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1416,9 +1416,9 @@ static void reds_info_new_channel(RedLinkInfo *link,
int connection_id)
if (reds_stream_is_ssl(link-stream)) {
reds_stream_set_info_flag(link-stream,
SPICE_CHANNEL_EVENT_FLAG_TLS);
}
-link-stream-info-connection_id = connection_id;
-link-stream-info-type = link-link_mess-channel_type;
-link-stream-info-id = link-link_mess-channel_id;
+reds_stream_set_channel(link-stream, connection_id,
+link-link_mess-channel_type,
+link-link_mess-channel_id);
reds_stream_push_channel_event(link-stream,
SPICE_CHANNEL_EVENT_INITIALIZED);
}
diff --git a/server/reds_stream.c b/server/reds_stream.c
index d2c05d9..6af3cd1 100644
--- a/server/reds_stream.c
+++ b/server/reds_stream.c
@@ -282,6 +282,15 @@ static void reds_stream_set_socket(RedsStream *stream,
int socket)
stream-info-plen_ext);
}
+
+void reds_stream_set_channel(RedsStream *stream, int connection_id,
+ int channel_type, int channel_id)
+{
+stream-info-connection_id = connection_id;
+stream-info-type = connection_id;
+stream-info-id = channel_type;
type became id.
+}
+
RedsStream *reds_stream_new(int socket)
{
RedsStream *stream;
diff --git a/server/reds_stream.h b/server/reds_stream.h
index add9b2e..64657c2 100644
--- a/server/reds_stream.h
+++ b/server/reds_stream.h
@@ -81,6 +81,8 @@ void reds_stream_free(RedsStream *s);
void reds_stream_push_channel_event(RedsStream *s, int event);
void reds_stream_remove_watch(RedsStream* s);
+void reds_stream_set_channel(RedsStream *stream, int connection_id,
+ int channel_type, int channel_id);
RedsStream *reds_stream_new(int socket);
bool reds_stream_is_ssl(RedsStream *stream);
RedsStreamSslStatus reds_stream_ssl_accept(RedsStream *stream);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] some question about spice client project cegui gui implement
On 12/23/2013 04:19 AM, feifei li wrote: Dear all: I read spice client project,find that gui is implement by CEGUI.The taharez_look.scheme,taharez_look.looknfeel,taharez_look.imageset files are provied by XML foemat in CEGUI system, but are provided by .c format in spice client project.I want to known how to convert xml format file to .c format file.Tell me the method please. Thanks! Hi Feifei, We have moved to developing spice-gtk, spicec is an old deprecated client no longer being maintained. We will accept patches for it but we don't actively work on it. To the point of the question, I don't know the answer. Alon ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] SPICE and guest breakout risk assessment
On 12/30/2013 08:44 AM, adrelanos wrote: Hi, I am currently working on testing out KVM as a platform for Whonix, a Debian based spin with anonymity enforcement via usage of virtual machines. All traffic from a workstation vm is forced through a Tor gateway on the second gateway vm. Safeguarding against high level attacks (0days and advanced persistent threats) is our top priority and so right now we are hammering out the details of what virtual hardware should be attached into the vms. In your opinion is enabling SPICE and 2D acceleration via QXL+vdagent in the guest, a security risk to the host? Consider this question in a scenario where the host is a RedHat derivative that has SElinux and secomp enabled for QEMU. We want to find out whether this is a case of security vs convenience. Enabling spice adds more code running on the host in the same context as the qemu process (libspice-server is linked to qemu), so I'd say yes (not sure what risk is acceptable, or what risk means exactly, but it is a risk in the english sense :). Thanks for you time. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Why spice server can't update area by tree？
On 12/08/2013 08:57 AM, thddu wrote: I found some guest applications create a lot of unnecessary qxl commands rendering. But update_area logic of spice server does not utilize the current tree. 1、Why spice server can't update area by tree? I think it's just a todo item. You can see commented code that does that, apparently the author decided it wasn't good enough. 2、How to use update area by tree? What do you mean? you need to write it, or fix the existing commented out part first. Howard ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: Problem after update windows VirtIO drivers
On 12/11/2013 11:27 AM, Vadim Rozenfeld wrote: On Tue, 2013-12-10 at 15:29 +0200, Alon Levy wrote: On 12/10/2013 04:24 AM, Vadim Rozenfeld wrote: - Original Message - From: Alon Levy al...@redhat.com To: Carlos Rodrigues c...@eurotux.com, kvm@vger.kernel.org, Vadim Rozenfeld vroze...@redhat.com Sent: Tuesday, December 10, 2013 3:45:32 AM Subject: Re: Problem after update windows VirtIO drivers On 12/09/2013 04:45 PM, Carlos Rodrigues wrote: Hello, After update the VirtIO drivers for Windows Server 2008 R2 64-bit, when i reboot virtual machine, the windows OS get stuck on loading bar. The VirtIO drivers is the latest stable that i made the download from http://alt.fedoraproject.org/pub/alt/virtio-win/stable/virtio-win-0.1-74.iso And i use version 1.2.1 of kvm and the OS of host is Centos 5.8. I try to install a fresh and clean version same Windows and same drivers and get the same problem. With virtio-win-0.1-52 version of drivers, the windows server works properly. I will use the oldest stable version of drivers, but anyone knows some issue with latest drivers? [VR] Hi Carlos, Could you please post the QEMU command line as well as output from 'info pci' I have an issue that also existed with 0.65, on windows 7 64 bit: when I have qxl enabled as well I get a crash shortly after initialization of qxl (at the login screen) in a memory management function of the qxl driver, indicating something overwrote parts of the allocators accounting structures. When I disable the virtio driver (leaving the virtio device) the problem goes away. Vadim, is this a known problem? (sorry for hijacking the thread) Does it crash into BSOD? Can you share the crash dump file? Yes, the stacktrace is in qxl, like I mentioned (DrvMouseMove) but that's not happening without the virtio driver being loaded. http://people.freedesktop.org/~alon/qxl-0.10-18-debug-virtio-0.74.DMP This time it happend in FlushReleaseRing-ReleaseOutput-DebugShowOutput path. It is a random crash? It happens almost immediately after entering the login screen, that is after display driver has been initialized and sent already some commands. But the stack trace is not the same always as you saw for yourself (thanks - I didn't even check, I assumed it was the same as the last dump). Btw, vioserial is the only one virtio driver in your system. Yep. If you are absolutely positive that the system doesn't crash without this driver, we can try running it under Driver Verifier control (http://support.microsoft.com/kb/244617) mostly interested in Memory Allocations checks. Yes, I'm positive. Thanks, I'll try that. Cheers, Vadim. Best regards, Vadim. Regards, -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem after update windows VirtIO drivers
On 12/10/2013 04:24 AM, Vadim Rozenfeld wrote: - Original Message - From: Alon Levy al...@redhat.com To: Carlos Rodrigues c...@eurotux.com, kvm@vger.kernel.org, Vadim Rozenfeld vroze...@redhat.com Sent: Tuesday, December 10, 2013 3:45:32 AM Subject: Re: Problem after update windows VirtIO drivers On 12/09/2013 04:45 PM, Carlos Rodrigues wrote: Hello, After update the VirtIO drivers for Windows Server 2008 R2 64-bit, when i reboot virtual machine, the windows OS get stuck on loading bar. The VirtIO drivers is the latest stable that i made the download from http://alt.fedoraproject.org/pub/alt/virtio-win/stable/virtio-win-0.1-74.iso And i use version 1.2.1 of kvm and the OS of host is Centos 5.8. I try to install a fresh and clean version same Windows and same drivers and get the same problem. With virtio-win-0.1-52 version of drivers, the windows server works properly. I will use the oldest stable version of drivers, but anyone knows some issue with latest drivers? [VR] Hi Carlos, Could you please post the QEMU command line as well as output from 'info pci' I have an issue that also existed with 0.65, on windows 7 64 bit: when I have qxl enabled as well I get a crash shortly after initialization of qxl (at the login screen) in a memory management function of the qxl driver, indicating something overwrote parts of the allocators accounting structures. When I disable the virtio driver (leaving the virtio device) the problem goes away. Vadim, is this a known problem? (sorry for hijacking the thread) Does it crash into BSOD? Can you share the crash dump file? Yes, the stacktrace is in qxl, like I mentioned (DrvMouseMove) but that's not happening without the virtio driver being loaded. http://people.freedesktop.org/~alon/qxl-0.10-18-debug-virtio-0.74.DMP Best regards, Vadim. Regards, -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem after update windows VirtIO drivers
On 12/09/2013 04:45 PM, Carlos Rodrigues wrote: Hello, After update the VirtIO drivers for Windows Server 2008 R2 64-bit, when i reboot virtual machine, the windows OS get stuck on loading bar. The VirtIO drivers is the latest stable that i made the download from http://alt.fedoraproject.org/pub/alt/virtio-win/stable/virtio-win-0.1-74.iso And i use version 1.2.1 of kvm and the OS of host is Centos 5.8. I try to install a fresh and clean version same Windows and same drivers and get the same problem. With virtio-win-0.1-52 version of drivers, the windows server works properly. I will use the oldest stable version of drivers, but anyone knows some issue with latest drivers? I have an issue that also existed with 0.65, on windows 7 64 bit: when I have qxl enabled as well I get a crash shortly after initialization of qxl (at the login screen) in a memory management function of the qxl driver, indicating something overwrote parts of the allocators accounting structures. When I disable the virtio driver (leaving the virtio device) the problem goes away. Vadim, is this a known problem? (sorry for hijacking the thread) Regards, -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Spice-devel] Mouse Edit Cursor invisible on dark backgrounds in Win 7 Guest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2013 05:06 PM, Lindsay Mathieson wrote: On Sat, 7 Dec 2013 09:21:44 AM Marian Krcmarik wrote: Most likely The problem you described is fixed by http://lists.freedesktop.org/archives/spice-devel/2013-October/015079.html, So The bug shouldn't be observed in latest release of spice-gtk 0.22. It may take time for that version to get into your distro so you may build spice-gtk yourself If It bothers you a lot. Thanks, will do. Would this fix apply to the windows client as well? because seeing the same behaviour . It should fix windows guests too, the fix doesn't use any API, it's purely math. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSpcUwAAoJEGSFt2Lm6PXulXQH/j1Bq1RoI33jNfjKmWNeRWVG 2VbH2G403jkNDQVjT5x9TusYOCpLMNFP+IENBh+hbqXgxDG1vYMdUM72pLbWqnHE oBh66AGrrqwkmz0McynDTX8mfmclDbXDIp6U6RJw/pBlCuEbyaiACQID4Xzw4dsQ 5HQrNT8zprWaChBDg2aam+lvbKdBprlKLVq/oiUUdMmQaRrJnWy5IYHSgAOs5/cm vKgxklwB8OUbAyIZlX72UnlutsoCIl/W3sbf4xAVI4D0cERU1vYKK+xwNF/UVjSS UYIYok0UvZVfoH2wWVkKZe9iInXPRIKgiBl+OYdd9ciY5MMii9B2RVOhOHU5i2o= =VNsh -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Qemu-devel] [PULL] libcacard fixes
Anthony, The following changes since commit a1d22a367d5780c9553b2cd5a24f665534ce6ed6: target-cris: Use new qemu_ld/st opcodes (2013-12-08 09:36:02 +0100) are available in the git repository at: git://people.freedesktop.org/~alon/qemu libcacard_ccid.4 for you to fetch changes up to 5ad04fb6f112cf2917909be4c22109dbb65fed18: libcacard: Fix compilation for older versions of glib (bug #1258168) (2013-12-09 12:19:05 +0200) Please pull, Thanks, Alon Stefan Weil (1): libcacard: Fix compilation for older versions of glib (bug #1258168) libcacard/vscclient.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 1.8.4.2
[Qemu-devel] [PULL] libcacard: Fix compilation for older versions of glib (bug #1258168)
From: Stefan Weil s...@weilnetz.de See https://bugs.launchpad.net/bugs/1258168 libcacard/vscclient.c: In function 'do_socket_read': libcacard/vscclient.c:410: warning: implicit declaration of function 'g_warn_if_reached' libcacard/vscclient.c:410: warning: nested extern declaration of 'g_warn_if_reached' libcacard/vscclient.c: In function 'main': libcacard/vscclient.c:763: warning: implicit declaration of function 'g_byte_array_unref' libcacard/vscclient.c:763: warning: nested extern declaration of 'g_byte_array_unref' ... libcacard/vscclient.o: In function `do_socket_read': libcacard/vscclient.c:410: undefined reference to `g_warn_if_reached' libcacard/vscclient.o: In function `main': libcacard/vscclient.c:763: undefined reference to `g_byte_array_unref' g_warn_if_reached was added in glib 2.16, and g_byte_array_unref is supported since glib 2.22. QEMU requires glib 2.12, so both names must not be used. Instead of showing a warning for code which should not be reached, vscclient better stop running, so g_warn_if_reached is not useful for vscclient. In libcacard/vsclient.c, g_byte_array_unref can be replaced by g_byte_array_free. This is not generally true, so adding a compatibility layer in include/glib-compat.h is no option here. Reported-by: Laurent Desnogues laurent.desnog...@gmail.com Reported-by: Don Slutz dsl...@verizon.com Signed-off-by: Stefan Weil s...@weilnetz.de --- libcacard/vscclient.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c index a3cb776..f1d46d3 100644 --- a/libcacard/vscclient.c +++ b/libcacard/vscclient.c @@ -407,7 +407,7 @@ do_socket_read(GIOChannel *source, } break; default: -g_warn_if_reached(); +g_assert_not_reached(); return FALSE; } @@ -760,7 +760,7 @@ main( g_io_channel_unref(channel_stdin); g_io_channel_unref(channel_socket); -g_byte_array_unref(socket_to_send); +g_byte_array_free(socket_to_send, TRUE); closesocket(sock); return 0; -- 1.8.4.2
Re: [Qemu-devel] [PATCH v2] libcacard: Fix compilation for older versions of glib (bug #1258168)
On 12/05/2013 08:41 PM, Stefan Weil wrote: See https://bugs.launchpad.net/bugs/1258168 libcacard/vscclient.c: In function 'do_socket_read': libcacard/vscclient.c:410: warning: implicit declaration of function 'g_warn_if_reached' libcacard/vscclient.c:410: warning: nested extern declaration of 'g_warn_if_reached' libcacard/vscclient.c: In function 'main': libcacard/vscclient.c:763: warning: implicit declaration of function 'g_byte_array_unref' libcacard/vscclient.c:763: warning: nested extern declaration of 'g_byte_array_unref' ... libcacard/vscclient.o: In function `do_socket_read': libcacard/vscclient.c:410: undefined reference to `g_warn_if_reached' libcacard/vscclient.o: In function `main': libcacard/vscclient.c:763: undefined reference to `g_byte_array_unref' g_warn_if_reached was added in glib 2.16, and g_byte_array_unref is supported since glib 2.22. QEMU requires glib 2.12, so both names must not be used. Instead of showing a warning for code which should not be reached, QEMU better stops running, so g_warn_if_reached is not useful for QEMU. Just note that this fix is in vscclient, so this code is not part of qemu executable. If you are using QEMU (all caps) as the whole project, the commit message is ok, but it should clarify this is about the separate vscclient executable. Other then that ACK, I can send a pull request with the commit message fixed as I suggested. In libcacard/vsclient.c, g_byte_array_unref can be replaced by g_byte_array_free. This is not generally true, so adding a compatibility layer in include/glib-compat.h is no option here. Reported-by: Laurent Desnogues laurent.desnog...@gmail.com Reported-by: Don Slutz dsl...@verizon.com Signed-off-by: Stefan Weil s...@weilnetz.de --- v2: Fix commit message and add missing parameter for g_byte_array_free. libcacard/vscclient.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libcacard/vscclient.c b/libcacard/vscclient.c index a3cb776..f1d46d3 100644 --- a/libcacard/vscclient.c +++ b/libcacard/vscclient.c @@ -407,7 +407,7 @@ do_socket_read(GIOChannel *source, } break; default: -g_warn_if_reached(); +g_assert_not_reached(); return FALSE; } @@ -760,7 +760,7 @@ main( g_io_channel_unref(channel_stdin); g_io_channel_unref(channel_socket); -g_byte_array_unref(socket_to_send); +g_byte_array_free(socket_to_send, TRUE); closesocket(sock); return 0;
Re: [Qemu-devel] [PATCH] spice: flip streaming video mode to off by default
On 12/02/2013 12:27 PM, Gerd Hoffmann wrote:
Video streaming detection heuristics in spice-server have problems
keeping modern desktop animations (as done by gnome shell) and real
video playback apart. This leads to jpeg compression artefacts on
your desktop, due to spice using mjpeg to send what it thinks is
a video stream.
Turn off video detection by default to avoid these artifacts.
Reviewed-by: Alon Levy al...@redhat.com
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
ui/spice-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ui/spice-core.c b/ui/spice-core.c
index e4d533d..9fb9544 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -776,6 +776,8 @@ void qemu_spice_init(void)
if (str) {
int streaming_video = parse_stream_video(str);
spice_server_set_streaming_video(spice_server, streaming_video);
+} else {
+spice_server_set_streaming_video(spice_server,
SPICE_STREAM_VIDEO_OFF);
}
spice_server_set_agent_mouse
Re: [Spice-devel] [PATCH spice-gtk 3/5] Add SpiceVMC GIOStream
On 11/18/2013 01:03 AM, Marc-André Lureau wrote: Hey Fedor On Sun, Nov 17, 2013 at 5:48 PM, Fedor Lyakhov fedor.lyak...@gmail.com wrote: Marc, What does VMC stand for here? Is it related to my idea of virtual media controller, or just a coincidence? It's a coincidence ;) Hans should know what it really stands for, it was introduced with USB redir channel. I think it is meant to be vm char device, because this channel kind can be associated with a qemu chardev. In practice, it allows a channel to stream arbitrary data, with spice server handling registration, authentication, migration, some flow control etc. To me, it's the easiest way to implement a new channel that reuse an existing protocol over Spice. I remembered it as virtual machine channel but char is more accurate, and I agree with the above explanation (I introduced it originally, I think two years ago?). ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 9/9] chardev: learn to keep running when vm is stopped
On 11/18/2013 12:28 PM, Marc-André Lureau wrote:
All chardev channels are stopped when calling spice_server_vm_stop(),
which prevents them from doing any i/o.
However, the Spice block device channel needs to keep running even when
the VM is stopped. It is entirely drived by the server, so it is
s/drived/drivven/
entirely to the server to deal with the channel running state (finish
s/to the/up to the/
all outstanding operations or block io).
Looks good,
ACK series.
---
server/char_device.c | 11 ++-
server/char_device.h | 1 +
server/reds.c| 1 +
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/server/char_device.c b/server/char_device.c
index 0cd5106..7b4c3f8 100644
--- a/server/char_device.c
+++ b/server/char_device.c
@@ -45,6 +45,7 @@ struct SpiceCharDeviceClientState {
};
struct SpiceCharDeviceState {
+int non_stop;
int running;
int active; /* has read/write been performed since the device was
started */
int wait_for_migrate_data;
@@ -803,12 +804,20 @@ void spice_char_device_start(SpiceCharDeviceState *dev)
void spice_char_device_stop(SpiceCharDeviceState *dev)
{
-spice_debug(dev_state %p, dev);
+spice_debug(char_device_stop %p: non_stop:%d, dev, dev-non_stop);
+
+if (dev-non_stop)
+return;
dev-running = FALSE;
dev-active = FALSE;
core-timer_cancel(dev-write_to_dev_timer);
}
+void spice_char_device_set_non_stop(SpiceCharDeviceState *dev, int non_stop)
+{
+dev-non_stop = non_stop;
+}
+
void spice_char_device_reset(SpiceCharDeviceState *dev)
{
RingItem *client_item;
diff --git a/server/char_device.h b/server/char_device.h
index c17a40d..e2b6c63 100644
--- a/server/char_device.h
+++ b/server/char_device.h
@@ -162,6 +162,7 @@ void spice_char_device_client_remove(SpiceCharDeviceState
*dev,
int spice_char_device_client_exists(SpiceCharDeviceState *dev,
RedClient *client);
+void spice_char_device_set_non_stop(SpiceCharDeviceState *dev, int non_stop);
void spice_char_device_start(SpiceCharDeviceState *dev);
void spice_char_device_stop(SpiceCharDeviceState *dev);
diff --git a/server/reds.c b/server/reds.c
index d9e04de..f1bad0c 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3669,6 +3669,7 @@ static int
spice_server_char_device_add_interface(SpiceServer *s,
}
else if (strcmp(char_device-subtype, SUBTYPE_NBD) == 0) {
dev_state = spicevmc_device_connect(char_device, SPICE_CHANNEL_NBD);
+spice_char_device_set_non_stop(dev_state, TRUE);
}
else if (strcmp(char_device-subtype, SUBTYPE_PORT) == 0) {
dev_state = spicevmc_device_connect(char_device, SPICE_CHANNEL_PORT);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 4/9] build-sys: bump current, as ABI is going to be broken next
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2013 02:21 PM, Christophe Fergeau wrote: On Mon, Nov 18, 2013 at 11:28:28AM +0100, Marc-André Lureau wrote: From: Marc-André Lureau marcandre.lur...@redhat.com --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 22e3889..7aa734e 100644 --- a/configure.ac +++ b/configure.ac @@ -13,9 +13,9 @@ AC_PREREQ([2.57]) # 4. Follow the libtool manual for the so version: # http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html -m4_define([SPICE_CURRENT], [9]) +m4_define([SPICE_CURRENT], [10]) m4_define([SPICE_REVISION], [0]) -m4_define([SPICE_AGE], [8]) +m4_define([SPICE_AGE], [0]) I'd rather we avoid breaking ABI 'just' for the NBD channel. What do you think is the correct criteria? Christophe ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSigjtAAoJEGSFt2Lm6PXuFWQH/1kLODRAk/e9DTKmDReznX7H wXHjuxuOo8GRY1ulYr3UN8i3j6J6PuVOardal4AsTdKoqzdLoq+vUhRrRa1Q5NPi 5oDZS2TbmzsPVbKTE2efWX9tp1fYga4DAIBTTS8F0oBDR5Y00Hr4Sh82nLQ2D1FV k70Pg2LZ8tcLKMY7uL60KDpVApnb5auVUIo1Kw9sVriu2EkJyXV55BrWoNQUIY+6 7TJ4gc6yy8rE33ShX9Rdn/AVUFComPkInsiAjeKJITuuMFJmne0gU/oqDtNRJ/V4 VIRykIc/JVR0HdRWMsdke85daSTMYiElDnpcOJSoVLeOyVgB6U3cfRNfnnB9LBw= =e398 -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [Qemu-devel] [PATCH 05/21] char: add qemu_chr_fe_event()
On 11/18/2013 02:25 PM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@redhat.com
The patch description is incomplete, or the patch should be split - this
patch also implements qemu_chr_fe_event for spiceport.
Signed-off-by: Marc-André Lureau marcandre.lur...@redhat.com
---
include/sysemu/char.h | 10 ++
qemu-char.c | 7 +++
spice-qemu-char.c | 10 ++
3 files changed, 27 insertions(+)
diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index ad101d9..d23c8f1 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -69,6 +69,7 @@ struct CharDriverState {
void (*chr_accept_input)(struct CharDriverState *chr);
void (*chr_set_echo)(struct CharDriverState *chr, bool echo);
void (*chr_set_fe_open)(struct CharDriverState *chr, int fe_open);
+void (*chr_fe_event)(struct CharDriverState *chr, int event);
void *opaque;
char *label;
char *filename;
@@ -138,6 +139,15 @@ void qemu_chr_fe_set_echo(struct CharDriverState *chr,
bool echo);
void qemu_chr_fe_set_open(struct CharDriverState *chr, int fe_open);
/**
+ * @qemu_chr_fe_event:
+ *
+ * Send an event from the back end to the front end.
+ *
+ * @event the event to send
+ */
+void qemu_chr_fe_event(CharDriverState *s, int event);
+
+/**
* @qemu_chr_fe_printf:
*
* Write to a character backend using a printf style interface.
diff --git a/qemu-char.c b/qemu-char.c
index e00f84c..418dc69 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3353,6 +3353,13 @@ void qemu_chr_fe_set_open(struct CharDriverState *chr,
int fe_open)
}
}
+void qemu_chr_fe_event(struct CharDriverState *chr, int event)
+{
+if (chr-chr_fe_event) {
+chr-chr_fe_event(chr, event);
+}
+}
+
int qemu_chr_fe_add_watch(CharDriverState *s, GIOCondition cond,
GIOFunc func, void *user_data)
{
diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index e074d9e..16439c5 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -222,6 +222,15 @@ static void spice_chr_set_fe_open(struct CharDriverState
*chr, int fe_open)
}
}
+static void spice_chr_fe_event(struct CharDriverState *chr, int event)
+{
+#if SPICE_SERVER_VERSION = 0x000c02
+SpiceCharDriver *s = chr-opaque;
+
+spice_server_port_event(s-sin, event);
+#endif
+}
+
static void print_allowed_subtypes(void)
{
const char** psubtype;
@@ -255,6 +264,7 @@ static CharDriverState *chr_open(const char *subtype)
chr-chr_close = spice_chr_close;
chr-chr_set_fe_open = spice_chr_set_fe_open;
chr-explicit_be_open = true;
+chr-chr_fe_event = spice_chr_fe_event;
QLIST_INSERT_HEAD(spice_chars, s, next);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 20/21] spice-core: allow an interface to be in AIO context
On 11/18/2013 02:25 PM, Marc-André Lureau wrote:
The Spice block driver must be able complete operations within a AIO
context only.
Spice is currently only running within the main loop, and doesn't allow
the block driver to complete operations, such as flush during migration.
This patch allows a Spice interface to be associated with a different
context. Currently, the interface user_data is simply used to
differentiate main loop from AIO, but could later be used to associate
an interface with a particular thread.
Signed-off-by: Marc-André Lureau marcandre.lur...@gmail.com
---
include/ui/qemu-spice.h | 2 +-
qemu-char.c | 2 +-
spice-qemu-char.c | 9 +++
ui/spice-core.c | 62
+++--
4 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/include/ui/qemu-spice.h b/include/ui/qemu-spice.h
index a93b4b2..d5ba702 100644
--- a/include/ui/qemu-spice.h
+++ b/include/ui/qemu-spice.h
@@ -48,7 +48,7 @@ int qemu_spice_migrate_info(const char *hostname, int port,
int tls_port,
void do_info_spice_print(Monitor *mon, const QObject *data);
void do_info_spice(Monitor *mon, QObject **ret_data);
-CharDriverState *qemu_chr_open_spice_vmc(const char *type);
+CharDriverState *qemu_chr_open_spice_vmc(const char *type, bool aio);
#if SPICE_SERVER_VERSION = 0x000c02
CharDriverState *qemu_chr_open_spice_port(const char *name);
void qemu_spice_register_ports(void);
diff --git a/qemu-char.c b/qemu-char.c
index 418dc69..bfac7bf 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3747,7 +3747,7 @@ ChardevReturn *qmp_chardev_add(const char *id,
ChardevBackend *backend,
#endif
#ifdef CONFIG_SPICE
case CHARDEV_BACKEND_KIND_SPICEVMC:
-chr = qemu_chr_open_spice_vmc(backend-spicevmc-type);
+chr = qemu_chr_open_spice_vmc(backend-spicevmc-type, false);
break;
case CHARDEV_BACKEND_KIND_SPICEPORT:
chr = qemu_chr_open_spice_port(backend-spiceport-fqdn);
diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 16439c5..421f7de 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -248,7 +248,7 @@ static void print_allowed_subtypes(void)
fprintf(stderr, \n);
}
-static CharDriverState *chr_open(const char *subtype)
+static CharDriverState *chr_open(const char *subtype, bool aio)
{
CharDriverState *chr;
SpiceCharDriver *s;
@@ -257,6 +257,7 @@ static CharDriverState *chr_open(const char *subtype)
s = g_malloc0(sizeof(SpiceCharDriver));
s-chr = chr;
s-active = false;
+s-sin.base.user_data = (void*)aio;
s-sin.subtype = g_strdup(subtype);
chr-opaque = s;
chr-chr_write = spice_chr_write;
@@ -271,7 +272,7 @@ static CharDriverState *chr_open(const char *subtype)
return chr;
}
-CharDriverState *qemu_chr_open_spice_vmc(const char *type)
+CharDriverState *qemu_chr_open_spice_vmc(const char *type, bool aio)
{
const char **psubtype = spice_server_char_device_recognized_subtypes();
@@ -291,7 +292,7 @@ CharDriverState *qemu_chr_open_spice_vmc(const char *type)
return NULL;
}
-return chr_open(type);
+return chr_open(type, aio);
}
#if SPICE_SERVER_VERSION = 0x000c02
@@ -305,7 +306,7 @@ CharDriverState *qemu_chr_open_spice_port(const char
*name)
return NULL;
}
-chr = chr_open(port);
+chr = chr_open(port, false);
s = chr-opaque;
s-sin.portname = g_strdup(name);
diff --git a/ui/spice-core.c b/ui/spice-core.c
index e4d533d..0f69630 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -53,34 +53,64 @@ static QemuThread me;
struct SpiceTimer {
QEMUTimer *timer;
+QEMUBH *bh;
QTAILQ_ENTRY(SpiceTimer) next;
};
static QTAILQ_HEAD(, SpiceTimer) timers = QTAILQ_HEAD_INITIALIZER(timers);
+#if SPICE_INTERFACE_CORE_MAJOR = 2
+static SpiceTimer *timer_add(SpiceTimerFunc func, void *opaque,
SpiceBaseInstance *sin)
+#else
static SpiceTimer *timer_add(SpiceTimerFunc func, void *opaque)
+#endif
{
SpiceTimer *timer;
timer = g_malloc0(sizeof(*timer));
-timer-timer = timer_new_ms(QEMU_CLOCK_REALTIME, func, opaque);
+
+#if SPICE_INTERFACE_CORE_MAJOR = 2
+bool aio = sin ? !!sin-user_data : false;
Shouldn't there be a cast there:
(bool)sin-user_data
?
+if (aio) {
+fprintf(stderr, AIO doesn't have timers yet, using BH\n);
+timer-bh = qemu_bh_new(func, opaque);
+} else
+#endif
+{
+timer-timer = timer_new_ms(QEMU_CLOCK_REALTIME, func, opaque);
+}
+
QTAILQ_INSERT_TAIL(timers, timer, next);
+
return timer;
}
static void timer_start(SpiceTimer *timer, uint32_t ms)
{
-timer_mod(timer-timer, qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + ms);
+if (timer-bh) {
+qemu_bh_schedule_idle(timer-bh); /* at least every 10ms, see
async.c */
+} else {
+
Re: [Spice-devel] [PATCH 4/9] build-sys: bump current, as ABI is going to be broken next
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2013 02:48 PM, Christophe Fergeau wrote: On Mon, Nov 18, 2013 at 02:32:45PM +0200, Alon Levy wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2013 02:21 PM, Christophe Fergeau wrote: On Mon, Nov 18, 2013 at 11:28:28AM +0100, Marc-André Lureau wrote: From: Marc-André Lureau marcandre.lur...@redhat.com --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 22e3889..7aa734e 100644 --- a/configure.ac +++ b/configure.ac @@ -13,9 +13,9 @@ AC_PREREQ([2.57]) # 4. Follow the libtool manual for the so version: # http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html - -m4_define([SPICE_CURRENT], [9]) +m4_define([SPICE_CURRENT], [10]) m4_define([SPICE_REVISION], [0]) -m4_define([SPICE_AGE], [8]) +m4_define([SPICE_AGE], [0]) I'd rather we avoid breaking ABI 'just' for the NBD channel. What do you think is the correct criteria? My criteria would be to never break it, so not really useful. I'd tend to return the question, if we break the ABI now (which hasn't been done in recent times), where do we stop? Some stuff in the Opus patches could also be made easier by breaking ABI, should we break ABI a second time there? I don't know. We can always keep both, in this case add a second add_watch function (add_watch_ext..) and possibly deprecate the former later. This is of course ugly, but doesn't break the ABI. Christophe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSihGFAAoJEGSFt2Lm6PXu0msH/1Pf8t6xhw+UPa1lQNqMfGVI gkHAcbfTbe82M4677CwzZmgYkR0qa0jwfgDroyhrUEL/znywiF0M1BR7IPX64QLO Hoxi8f7oSJPL31tOmtVoa9VZ7lsilJLhvXque83eBElCZL3G+6risSJeXLWLMY1r 6wgpTCPpWgNmP3qgxD6MoFRHBW6dQamF7HPOyT+IM0Ioelr9n36M2koVzlGVCv65 bxp7PYJHMQ4R0cMGHltnbiiRLpMBXFWbXO7Hn1t5o+KgXxs6XRd/Z6Qy7Ilb+ttr KxmoOLmTNVlkQ3lk9lQoXKU3/4t1SSiRgh3iangeL5gd7/MxZO2WPjl3nw++ugM= =Ejex -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 4/9] build-sys: bump current, as ABI is going to be broken next
I'd rather we avoid breaking ABI 'just' for the NBD channel.
What do you think is the correct criteria?
My criteria would be to never break it, so not really useful. I'd
tend to return the question, if we break the ABI now (which hasn't
been done in recent times), where do we stop? Some stuff in the
Opus patches could also be made easier by breaking ABI, should we
break ABI a second time there?
I don't know. We can always keep both, in this case add a second
add_watch function (add_watch_ext..) and possibly deprecate the former
later. This is of course ugly, but doesn't break the ABI.
It's changing the size of SpiceCoreInterface, that would break it too.
We would probably need a different struct interface.
Another problem is SpiceBaseInterface, where I added a user_data
pointer. This could be hidden in a private struct and accessors.
I meant BaseInstance.
Well, we suck. This instance could have been passed to qemu/users via
pointer and not embedded in any structs, and we wouldn't have this
problem. We could do it now, which would also break the ABI. Or we could
have another set of API's,
spice_new_{mouse,char_device,kbd,tablet,migrate,playback,record}_instance,
to be used with the new watch_add timer_add.
Not sure it is worth the work.
Christophe
--
Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Qemu-devel] [PATCH 05/21] char: add qemu_chr_fe_event()
On 11/18/2013 02:25 PM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@redhat.com
The patch description is incomplete, or the patch should be split - this
patch also implements qemu_chr_fe_event for spiceport.
Signed-off-by: Marc-André Lureau marcandre.lur...@redhat.com
---
include/sysemu/char.h | 10 ++
qemu-char.c | 7 +++
spice-qemu-char.c | 10 ++
3 files changed, 27 insertions(+)
diff --git a/include/sysemu/char.h b/include/sysemu/char.h
index ad101d9..d23c8f1 100644
--- a/include/sysemu/char.h
+++ b/include/sysemu/char.h
@@ -69,6 +69,7 @@ struct CharDriverState {
void (*chr_accept_input)(struct CharDriverState *chr);
void (*chr_set_echo)(struct CharDriverState *chr, bool echo);
void (*chr_set_fe_open)(struct CharDriverState *chr, int fe_open);
+void (*chr_fe_event)(struct CharDriverState *chr, int event);
void *opaque;
char *label;
char *filename;
@@ -138,6 +139,15 @@ void qemu_chr_fe_set_echo(struct CharDriverState *chr,
bool echo);
void qemu_chr_fe_set_open(struct CharDriverState *chr, int fe_open);
/**
+ * @qemu_chr_fe_event:
+ *
+ * Send an event from the back end to the front end.
+ *
+ * @event the event to send
+ */
+void qemu_chr_fe_event(CharDriverState *s, int event);
+
+/**
* @qemu_chr_fe_printf:
*
* Write to a character backend using a printf style interface.
diff --git a/qemu-char.c b/qemu-char.c
index e00f84c..418dc69 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3353,6 +3353,13 @@ void qemu_chr_fe_set_open(struct CharDriverState *chr,
int fe_open)
}
}
+void qemu_chr_fe_event(struct CharDriverState *chr, int event)
+{
+if (chr-chr_fe_event) {
+chr-chr_fe_event(chr, event);
+}
+}
+
int qemu_chr_fe_add_watch(CharDriverState *s, GIOCondition cond,
GIOFunc func, void *user_data)
{
diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index e074d9e..16439c5 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -222,6 +222,15 @@ static void spice_chr_set_fe_open(struct CharDriverState
*chr, int fe_open)
}
}
+static void spice_chr_fe_event(struct CharDriverState *chr, int event)
+{
+#if SPICE_SERVER_VERSION = 0x000c02
+SpiceCharDriver *s = chr-opaque;
+
+spice_server_port_event(s-sin, event);
+#endif
+}
+
static void print_allowed_subtypes(void)
{
const char** psubtype;
@@ -255,6 +264,7 @@ static CharDriverState *chr_open(const char *subtype)
chr-chr_close = spice_chr_close;
chr-chr_set_fe_open = spice_chr_set_fe_open;
chr-explicit_be_open = true;
+chr-chr_fe_event = spice_chr_fe_event;
QLIST_INSERT_HEAD(spice_chars, s, next);
Re: [Qemu-devel] [Spice-devel] [PATCH 20/21] spice-core: allow an interface to be in AIO context
On 11/18/2013 02:25 PM, Marc-André Lureau wrote:
The Spice block driver must be able complete operations within a AIO
context only.
Spice is currently only running within the main loop, and doesn't allow
the block driver to complete operations, such as flush during migration.
This patch allows a Spice interface to be associated with a different
context. Currently, the interface user_data is simply used to
differentiate main loop from AIO, but could later be used to associate
an interface with a particular thread.
Signed-off-by: Marc-André Lureau marcandre.lur...@gmail.com
---
include/ui/qemu-spice.h | 2 +-
qemu-char.c | 2 +-
spice-qemu-char.c | 9 +++
ui/spice-core.c | 62
+++--
4 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/include/ui/qemu-spice.h b/include/ui/qemu-spice.h
index a93b4b2..d5ba702 100644
--- a/include/ui/qemu-spice.h
+++ b/include/ui/qemu-spice.h
@@ -48,7 +48,7 @@ int qemu_spice_migrate_info(const char *hostname, int port,
int tls_port,
void do_info_spice_print(Monitor *mon, const QObject *data);
void do_info_spice(Monitor *mon, QObject **ret_data);
-CharDriverState *qemu_chr_open_spice_vmc(const char *type);
+CharDriverState *qemu_chr_open_spice_vmc(const char *type, bool aio);
#if SPICE_SERVER_VERSION = 0x000c02
CharDriverState *qemu_chr_open_spice_port(const char *name);
void qemu_spice_register_ports(void);
diff --git a/qemu-char.c b/qemu-char.c
index 418dc69..bfac7bf 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3747,7 +3747,7 @@ ChardevReturn *qmp_chardev_add(const char *id,
ChardevBackend *backend,
#endif
#ifdef CONFIG_SPICE
case CHARDEV_BACKEND_KIND_SPICEVMC:
-chr = qemu_chr_open_spice_vmc(backend-spicevmc-type);
+chr = qemu_chr_open_spice_vmc(backend-spicevmc-type, false);
break;
case CHARDEV_BACKEND_KIND_SPICEPORT:
chr = qemu_chr_open_spice_port(backend-spiceport-fqdn);
diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 16439c5..421f7de 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -248,7 +248,7 @@ static void print_allowed_subtypes(void)
fprintf(stderr, \n);
}
-static CharDriverState *chr_open(const char *subtype)
+static CharDriverState *chr_open(const char *subtype, bool aio)
{
CharDriverState *chr;
SpiceCharDriver *s;
@@ -257,6 +257,7 @@ static CharDriverState *chr_open(const char *subtype)
s = g_malloc0(sizeof(SpiceCharDriver));
s-chr = chr;
s-active = false;
+s-sin.base.user_data = (void*)aio;
s-sin.subtype = g_strdup(subtype);
chr-opaque = s;
chr-chr_write = spice_chr_write;
@@ -271,7 +272,7 @@ static CharDriverState *chr_open(const char *subtype)
return chr;
}
-CharDriverState *qemu_chr_open_spice_vmc(const char *type)
+CharDriverState *qemu_chr_open_spice_vmc(const char *type, bool aio)
{
const char **psubtype = spice_server_char_device_recognized_subtypes();
@@ -291,7 +292,7 @@ CharDriverState *qemu_chr_open_spice_vmc(const char *type)
return NULL;
}
-return chr_open(type);
+return chr_open(type, aio);
}
#if SPICE_SERVER_VERSION = 0x000c02
@@ -305,7 +306,7 @@ CharDriverState *qemu_chr_open_spice_port(const char
*name)
return NULL;
}
-chr = chr_open(port);
+chr = chr_open(port, false);
s = chr-opaque;
s-sin.portname = g_strdup(name);
diff --git a/ui/spice-core.c b/ui/spice-core.c
index e4d533d..0f69630 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -53,34 +53,64 @@ static QemuThread me;
struct SpiceTimer {
QEMUTimer *timer;
+QEMUBH *bh;
QTAILQ_ENTRY(SpiceTimer) next;
};
static QTAILQ_HEAD(, SpiceTimer) timers = QTAILQ_HEAD_INITIALIZER(timers);
+#if SPICE_INTERFACE_CORE_MAJOR = 2
+static SpiceTimer *timer_add(SpiceTimerFunc func, void *opaque,
SpiceBaseInstance *sin)
+#else
static SpiceTimer *timer_add(SpiceTimerFunc func, void *opaque)
+#endif
{
SpiceTimer *timer;
timer = g_malloc0(sizeof(*timer));
-timer-timer = timer_new_ms(QEMU_CLOCK_REALTIME, func, opaque);
+
+#if SPICE_INTERFACE_CORE_MAJOR = 2
+bool aio = sin ? !!sin-user_data : false;
Shouldn't there be a cast there:
(bool)sin-user_data
?
+if (aio) {
+fprintf(stderr, AIO doesn't have timers yet, using BH\n);
+timer-bh = qemu_bh_new(func, opaque);
+} else
+#endif
+{
+timer-timer = timer_new_ms(QEMU_CLOCK_REALTIME, func, opaque);
+}
+
QTAILQ_INSERT_TAIL(timers, timer, next);
+
return timer;
}
static void timer_start(SpiceTimer *timer, uint32_t ms)
{
-timer_mod(timer-timer, qemu_clock_get_ms(QEMU_CLOCK_REALTIME) + ms);
+if (timer-bh) {
+qemu_bh_schedule_idle(timer-bh); /* at least every 10ms, see
async.c */
+} else {
+
Re: [Qemu-devel] [PATCH] qxl: replace pipe signaling with bottom half
On 10/30/2013 10:17 AM, Gerd Hoffmann wrote:
qxl creates a pipe, then writes something to it to wake up the iothread
from the spice server thread to raise an irq. These days qemu bottom
halves can be scheduled from threads and signals, so there is no reason
to do this any more. Time to clean it up.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Reviewed-by: Alon Levy al...@redhat.com
---
hw/display/qxl.c | 33 +++--
hw/display/qxl.h | 3 +--
2 files changed, 4 insertions(+), 32 deletions(-)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index de835d6..41c34b1 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -1701,15 +1701,9 @@ static const MemoryRegionOps qxl_io_ops = {
},
};
-static void pipe_read(void *opaque)
+static void qxl_update_irq_bh(void *opaque)
{
PCIQXLDevice *d = opaque;
-char dummy;
-int len;
-
-do {
-len = read(d-pipe[0], dummy, sizeof(dummy));
-} while (len == sizeof(dummy));
qxl_update_irq(d);
}
@@ -1730,28 +1724,7 @@ static void qxl_send_events(PCIQXLDevice *d, uint32_t
events)
if ((old_pending le_events) == le_events) {
return;
}
-if (qemu_thread_is_self(d-main)) {
-qxl_update_irq(d);
-} else {
-if (write(d-pipe[1], d, 1) != 1) {
-dprint(d, 1, %s: write to pipe failed\n, __func__);
-}
-}
-}
-
-static void init_pipe_signaling(PCIQXLDevice *d)
-{
-if (pipe(d-pipe) 0) {
-fprintf(stderr, %s:%s: qxl pipe creation failed\n,
-__FILE__, __func__);
-exit(1);
-}
-fcntl(d-pipe[0], F_SETFL, O_NONBLOCK);
-fcntl(d-pipe[1], F_SETFL, O_NONBLOCK);
-fcntl(d-pipe[0], F_SETOWN, getpid());
-
-qemu_thread_get_self(d-main);
-qemu_set_fd_handler(d-pipe[0], pipe_read, NULL, d);
+qemu_bh_schedule(d-update_irq);
}
/* graphics console */
@@ -2044,7 +2017,7 @@ static int qxl_init_common(PCIQXLDevice *qxl)
}
qemu_add_vm_change_state_handler(qxl_vm_change_state_handler, qxl);
-init_pipe_signaling(qxl);
+qxl-update_irq = qemu_bh_new(qxl_update_irq_bh, qxl);
qxl_reset_state(qxl);
qxl-update_area_bh = qemu_bh_new(qxl_render_update_area_bh, qxl);
diff --git a/hw/display/qxl.h b/hw/display/qxl.h
index 84f0182..c5de3d7 100644
--- a/hw/display/qxl.h
+++ b/hw/display/qxl.h
@@ -81,8 +81,7 @@ typedef struct PCIQXLDevice {
QemuMutex track_lock;
/* thread signaling */
-QemuThread main;
-intpipe[2];
+QEMUBH *update_irq;
/* ram pci bar */
QXLRam *ram;
[Spice-devel] [PATCH xf86-video-qxl 1/2] spiceqxl_util.[hc]: add copyright license headers
Signed-off-by: Alon Levy al...@redhat.com --- src/spiceqxl_util.c | 22 ++ src/spiceqxl_util.h | 22 ++ 2 files changed, 44 insertions(+) diff --git a/src/spiceqxl_util.c b/src/spiceqxl_util.c index 49cd5ab..975467d 100644 --- a/src/spiceqxl_util.c +++ b/src/spiceqxl_util.c @@ -1,3 +1,25 @@ +/* + * Copyright 2013 Red Hat, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * on the rights to use, copy, modify, merge, publish, distribute, sub + * license, and/or sell copies of the Software, and to permit persons to whom + * the Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER + * IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + */ + #include config.h #include unistd.h diff --git a/src/spiceqxl_util.h b/src/spiceqxl_util.h index 4726bc1..52b3053 100644 --- a/src/spiceqxl_util.h +++ b/src/spiceqxl_util.h @@ -1,3 +1,25 @@ +/* + * Copyright 2013 Red Hat, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the Software), + * to deal in the Software without restriction, including without limitation + * on the rights to use, copy, modify, merge, publish, distribute, sub + * license, and/or sell copies of the Software, and to permit persons to whom + * the Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER + * IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + */ + #ifndef SPICEQXL_UTIL_H #define SPICEQXL_UTIL_H -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Release timing / strategy?
On 10/25/2013 07:01 PM, Jeremy White wrote: I've just now submitted updated spice-html5 packages to bohdi, so hopefully Fedora users will able to run an updated version shortly and stop having the missing minus key :-/. But I don't have a strategy for release timing. The html5 client doesn't tend to have obvious major points; it's little bits here and there, which I mostly roll up as the mood strikes me. I get the sense that the other parts of Spice are much the same. For example, the xf86-video-qxl driver went years without a new release, despite steady development. Does it make sense to create some sort of release timing? Perhaps try to have a new rollup of packages with each Fedora release? I'm mostly looking for an algorithm I can use to remind me to update the Fedora packages again someday :-/. We have a much neglected page for release planning on the wiki. The wiki needs some love since you can't log into it currently, but other then that (I intend to fix this tomorrow) it's a good idea, and since Fedora releases every 6 months (kinda) it sounds like an ok plan. Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH spice-common] spice.proto: fix uninitalized variable in demarshaller
Our automatically generated marshallers use temporary variables whose
name is based on the field, without checking for shadowing. This bites
us in one location that is fixed by this patch. A better solution would
be to fix the marshaller, but it's more then I want to bite right now.
RHBZ: 1021995
---
common/messages.h | 2 +-
spice.proto | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/messages.h b/common/messages.h
index a8a0eee..8ca5385 100644
--- a/common/messages.h
+++ b/common/messages.h
@@ -542,7 +542,7 @@ typedef struct SpiceMsgcTunnelAddGenericService {
uint64_t description;
union {
SpiceMsgTunnelIpInfo ip;
-} u;
+} u2;
} SpiceMsgcTunnelAddGenericService;
typedef struct SpiceMsgcTunnelRemoveService {
diff --git a/spice.proto b/spice.proto
index 04e7ea4..b4920f5 100644
--- a/spice.proto
+++ b/spice.proto
@@ -1210,7 +1210,7 @@ channel TunnelChannel : BaseChannel {
switch (type) {
case IPP:
TunnelIpInfo ip @ctype(SpiceMsgTunnelIpInfo);
- } u;
+ } u2;
} @ctype(SpiceMsgcTunnelAddGenericService) service_add = 101;
message {
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-common] spice.proto: fix uninitalized variable in demarshaller
On 10/22/2013 04:47 PM, Alon Levy wrote:
Our automatically generated marshallers use temporary variables whose
name is based on the field, without checking for shadowing. This bites
us in one location that is fixed by this patch. A better solution would
be to fix the marshaller, but it's more then I want to bite right now.
s/marshaller/generator/
I'll fix it before pushing.
RHBZ: 1021995
---
common/messages.h | 2 +-
spice.proto | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/messages.h b/common/messages.h
index a8a0eee..8ca5385 100644
--- a/common/messages.h
+++ b/common/messages.h
@@ -542,7 +542,7 @@ typedef struct SpiceMsgcTunnelAddGenericService {
uint64_t description;
union {
SpiceMsgTunnelIpInfo ip;
-} u;
+} u2;
} SpiceMsgcTunnelAddGenericService;
typedef struct SpiceMsgcTunnelRemoveService {
diff --git a/spice.proto b/spice.proto
index 04e7ea4..b4920f5 100644
--- a/spice.proto
+++ b/spice.proto
@@ -1210,7 +1210,7 @@ channel TunnelChannel : BaseChannel {
switch (type) {
case IPP:
TunnelIpInfo ip @ctype(SpiceMsgTunnelIpInfo);
- } u;
+ } u2;
} @ctype(SpiceMsgcTunnelAddGenericService) service_add = 101;
message {
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH xf86-video-qxl] tests/xspice_util.py: fix hardcoded port
--- tests/xspice_util.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/xspice_util.py b/tests/xspice_util.py index a2e8578..409a0fc 100755 --- a/tests/xspice_util.py +++ b/tests/xspice_util.py @@ -57,7 +57,7 @@ def launch_xspice(port): if not os.path.exists(basedir): os.mkdir(basedir) assert(os.path.exists(basedir)) -xspice = Process.new(['../scripts/Xspice', '--port', '8000', '--auto', '--audio-fifo-dir', basedir, '--disable-ticketing', ':15.0']) +xspice = Process.new(['../scripts/Xspice', '--port', str(port), '--auto', '--audio-fifo-dir', basedir, '--disable-ticketing', ':15.0']) xspice.audio_fifo_dir = basedir return xspice -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 1/5] spiceqxl_spice_server: no need to call spice_server_set_noauth twice
---
src/spiceqxl_spice_server.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/spiceqxl_spice_server.c b/src/spiceqxl_spice_server.c
index 63a3179..14ee752 100644
--- a/src/spiceqxl_spice_server.c
+++ b/src/spiceqxl_spice_server.c
@@ -254,9 +254,6 @@ void xspice_set_spice_server_options(OptionInfoPtr options)
exit(1);
#endif
}
-if (disable_ticketing) {
-spice_server_set_noauth(spice_server);
-}
#if SPICE_SERVER_VERSION = 0x000801
/* we still don't actually support agent in xspice, but this
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 2/5] xspice: chown both files used by vdagent for suid Xorg case
When running a suid Xorg mkfifo and bind produce files owned by root.
Change the ownership so that the user launched vdagent vdagentd can
write to them. This also makes it easier to cleanup the files from the
Xspice process that is not running as root (and is launching both
vdagent vdagentd, hence they are not running as root either).
The patch adds two new parameters, uid and gid of the agent used files,
namely the virtio unix domain socket and the uinput fifo.
---
scripts/Xspice | 5 -
src/Makefile.am| 2 ++
src/qxl.h | 2 ++
src/qxl_driver.c | 4
src/spiceqxl_uinput.c | 2 ++
src/spiceqxl_util.c| 22 ++
src/spiceqxl_util.h| 8
src/spiceqxl_vdagent.c | 2 ++
8 files changed, 46 insertions(+), 1 deletion(-)
create mode 100644 src/spiceqxl_util.c
create mode 100644 src/spiceqxl_util.h
diff --git a/scripts/Xspice b/scripts/Xspice
index 17439a1..34a5fcc 100755
--- a/scripts/Xspice
+++ b/scripts/Xspice
@@ -91,6 +91,8 @@ parser.add_argument('--vdagent-uinput-path',
default='/tmp/xspice-uinput', help=
parser.add_argument('--vdagentd-exec', default='spice-vdagentd')
parser.add_argument('--vdagent-exec', default='spice-vdagent')
parser.add_argument('--vdagent-no-launch', default=True, action='store_false',
dest='vdagent_launch')
+parser.add_argument('--vdagent-uid', default=str(os.getuid()))
+parser.add_argument('--vdagent-gid', default=str(os.getgid()))
parser.add_argument('--audio-fifo-dir', default='')
#TODO
@@ -231,7 +233,8 @@ var_args = ['port', 'tls_port', 'disable_ticketing',
'tls_ciphers', 'dh_file', 'password', 'image_compression',
'jpeg_wan_compression', 'zlib_glz_wan_compression',
'streaming_video', 'deferred_fps', 'exit_on_disconnect',
-'vdagent_enabled', 'vdagent_virtio_path', 'vdagent_uinput_path']
+'vdagent_enabled', 'vdagent_virtio_path', 'vdagent_uinput_path',
+'vdagent_uid', 'vdagent_gid']
for arg in var_args:
if getattr(args, arg):
diff --git a/src/Makefile.am b/src/Makefile.am
index 4c4ae40..bf50ae1 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -79,6 +79,8 @@ spiceqxl_drv_la_SOURCES = \
qxl.h \
qxl_option_helpers.c\
qxl_option_helpers.h\
+ spiceqxl_util.h \
+ spiceqxl_util.c \
spiceqxl_spice_server.c \
spiceqxl_spice_server.h \
spiceqxl_io_port.c \
diff --git a/src/qxl.h b/src/qxl.h
index c699c58..a44875b 100644
--- a/src/qxl.h
+++ b/src/qxl.h
@@ -147,6 +147,8 @@ enum {
OPTION_SPICE_VDAGENT_ENABLED,
OPTION_SPICE_VDAGENT_VIRTIO_PATH,
OPTION_SPICE_VDAGENT_UINPUT_PATH,
+OPTION_SPICE_VDAGENT_UID,
+OPTION_SPICE_VDAGENT_GID,
#endif
OPTION_COUNT,
};
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index 91ba6c2..29b1551 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -142,6 +142,10 @@ const OptionInfoRec DefaultOptions[] =
SpiceVdagentVirtioPath, OPTV_STRING,{.str =
spice_vdagent_virtio_path_default}, FALSE},
{ OPTION_SPICE_VDAGENT_UINPUT_PATH,
SpiceVdagentUinputPath, OPTV_STRING,{.str =
spice_vdagent_uinput_path_default}, FALSE},
+{ OPTION_SPICE_VDAGENT_UID,
+ SpiceVdagentUid, OPTV_INTEGER,{0}, FALSE},
+{ OPTION_SPICE_VDAGENT_GID,
+ SpiceVdagentGid, OPTV_INTEGER,{0}, FALSE},
#endif
{ -1, NULL, OPTV_NONE, {0}, FALSE }
diff --git a/src/spiceqxl_uinput.c b/src/spiceqxl_uinput.c
index 443f931..1e61907 100644
--- a/src/spiceqxl_uinput.c
+++ b/src/spiceqxl_uinput.c
@@ -13,6 +13,7 @@
#include linux/uinput.h
#include qxl_option_helpers.h
+#include spiceqxl_util.h
#include spiceqxl_inputs.h
#include spiceqxl_uinput.h
@@ -113,6 +114,7 @@ void spiceqxl_uinput_init(qxl_screen_t *qxl)
uinput_filename, strerror(errno));
return;
}
+spiceqxl_chown_agent_file(qxl, uinput_filename);
uinput_fd = open(uinput_filename, O_RDONLY | O_NONBLOCK, 0666);
if (uinput_fd == -1) {
fprintf(stderr, spice: failed creating uinput file %s: %s\n,
diff --git a/src/spiceqxl_util.c b/src/spiceqxl_util.c
new file mode 100644
index 000..49cd5ab
--- /dev/null
+++ b/src/spiceqxl_util.c
@@ -0,0 +1,22 @@
+#include config.h
+
+#include unistd.h
+#include string.h
+#include errno.h
+
+#include qxl_option_helpers.h
+#include spiceqxl_util.h
+
+void spiceqxl_chown_agent_file(qxl_screen_t *qxl, const char *filename)
+{
+int uid, gid;
+
+uid = get_int_option(qxl-options, OPTION_SPICE_VDAGENT_UID,
XSPICE_VDAGENT_UID);
+gid = get_int_option(qxl-options, OPTION_SPICE_VDAGENT_GID,
XSPICE_VDAGENT_GID);
+if (uid gid) {
+if (chown(filename, uid, gid) != 0) {
+fprintf(stderr, spice: failed to chain ownership of
[Spice-devel] [PATCH 3/5] Xspice: cleanup non regular files too
--- scripts/Xspice | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Xspice b/scripts/Xspice index 34a5fcc..be87c08 100755 --- a/scripts/Xspice +++ b/scripts/Xspice @@ -159,7 +159,7 @@ cleanup_processes = [] def cleanup(*args): for f in cleanup_files: -if os.path.isfile(f): +if os.path.exists(f): os.remove(f) for p in cleanup_processes: p.kill() -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 5/5] Xspice: cleanup vdagent files
--- scripts/Xspice | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/Xspice b/scripts/Xspice index 9b82bfe..b1528f9 100755 --- a/scripts/Xspice +++ b/scripts/Xspice @@ -278,6 +278,7 @@ if args.vdagent_enabled: for f in [vdagentd_uds, args.vdagent_virtio_path, args.vdagent_uinput_path]: if os.path.exists(f): os.unlink(f) +cleanup_files.extend([args.vdagent_virtio_path, args.vdagent_uinput_path]) xorg = launch(executable=args.xorg, args=exec_args + xorg_args) time.sleep(2) -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 4/5] Xspice: fix cleanup when some processes are already dead
--- scripts/Xspice | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/scripts/Xspice b/scripts/Xspice index be87c08..9b82bfe 100755 --- a/scripts/Xspice +++ b/scripts/Xspice @@ -162,9 +162,15 @@ def cleanup(*args): if os.path.exists(f): os.remove(f) for p in cleanup_processes: -p.kill() +try: +p.kill() +except OSError: +pass for p in cleanup_processes: -p.wait() +try: +p.wait() +except OSError: +pass del cleanup_processes[:] def launch(*args, **kw): -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[ANNOUNCE] xf86-video-qxl 0.1.1
I'm happy to announce a new xf86-video-qxl release, 0.1.1. Here is the list of
changes:
Major changes in 0.1.1
==
KMS support
DFPS available to guest driver too
Xspice audio agent support
GPL code removed (EDID)
Warnings squash
Bug fixes (numbers are Red Hat Bugzilla bug ids):
883578 - remote-viewer gets frozen after migration of guest with video playback
968931 - Crash in Xspice after closing tab with spice-html5
894421 - Small change in guests resolution results in wrong resolution
Adam Jackson (1):
Remove mibstore.h
Alon Levy (23):
spiceqxl_main_loop: fix use of watch after removal
fix a bunch of warnings - unused variables, labels, code
fix undefined symbol qxl_enter_vt_kms for XSPICE
xspice: support sending monitors config
xspice: zero memory on allocation, fix uninitialized use (valgrind
reported)
spiceqxl_inputs: expose buttons position api for agent usage
qxl_option_helpers: add required includes
xspice: add vdagent support
xspice: add uinput support to vdagent support
Xspice: use subprocess.Popen, nicer cleanup of files/processes
Xspice: correct doc string
Xspice: require display parameter, and set if earlier in environment
Xspice: vdagent{,d} launching support
qxl_get_formats: use surface enum, not bitmap (fixes clang warning)
spiceqxl_display: add noreturn attribute (silence clang warning)
uxa: use PIXMAN consts instead of PICT in some places (silence clang
warning)
Xspice: add --audio-fifo-dir
spiceqxl_audio: fix possible buffer overflow (clang)
qxl_image: fix build break once MIN/MAX switched to spice-protocol
Xspice: kill Xorg process on SIGTERM
xspice: add tests for audio remoting
Release 0.1.1
fix make dist
Andrew Eikum (1):
Implement sending audio to the client from a directory of FIFO queues
Cole Robinson (1):
qxl: Report actual module version
Dave Airlie (31):
qxl: split uxa related code into separate file
qxl: split user modesetting code and crtc code out.
qxl: move io functions to a separate file
qxl_mem: drop unused if 0 code.
qxl: move mem slots code to qxl_mem.c
qxl: move garbage collector + alloc into qxl_mem.c
qxl: move mspace setup to qxl_mem.c
uxa: port over tiled fill code from EXA
qxl: split surface struct out into its own header file.
qxl: pass qxl instead of surface cache to some functions
qxl_surface: move to using struct to avoid ordering issues with typedef.
qxl: fix memory leak on driver exit.
qxl: split common pre init code out from qxl pre init
qxl_edid: add missing config.h
qxl: pass surface struct instead of ids in drawable functions.
qxl: add direct pointer from qxl surface to qxl screen
qxl: abstract object allocation away from surface/image/cursor code
qxl: separate surface ums code out into separate file
qxl: fix build in koji
qxl: fix xspice build due to missing include.
qxl: use u64_to_pointer to avoid warnings when building on i686
qxl: drop pointless and wrong memset.
qxl: add KMS support v1.2
qxl/kms: recreate the host image upon resize
qxl: don't enable kms unless we can find qxl_drm.h
qxl: fix 32-bit mmaps
qxl: fix issue with resizing dev_image improperly
qxl: add uevent handler support
qxl: drop GPL code from qxl driver
qxl: fix broken cursor hotspot on KMS driver
fix build with --disable-kms
Jeremy White (33):
Change include paths to fix rare compilation issue.
Unify memory management for the primary screen.
Add a DeferredFPS option.
Shift the uxa function initialization to a separate function.
Add a deferred frames mode.
Implement copy with fbFill.
Implement prepare_copy using GC functions.
Enable the use of SpiceExitOnDisconnect so that Xspice can be configured
Establish a preferred default of 1024x768 correctly.
We're uploading a drawable from the primary surface, use it.
Initialize our update region at surface creation, avoids 0 size regions
Handle cache and surface options the same way we handle all options.
Add missing options to the example xorg.conf file.
Consolidate and document the missing parameters
Add a '--auto' flag to create a temporary xorg.conf file.
Enable the deferred-fps and exit-on-disconnect options
Add a --xsession option, to allow for an automatic start of an xsession
script
Add an example stanza for the FIFO dir logic.
More correctly signal that we only want the first head connected at start.
Eliminate gcc warning on duplicate use of ARRAY_SIZE by Xorg.
Removed unused local variables
Document a meaningful warning.
Eliminate a printf format warning on 32 bit systems.
Actually request the forcibly inline functions
[Spice-devel] [PATCH] qxl_image: fix build break once MIN/MAX switched to spice-protocol
In commit 5e122e4ab1ac35186cc610cd0d518cfd5e78d902 --- src/qxl_image.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qxl_image.c b/src/qxl_image.c index 2349fca..0a0ca30 100644 --- a/src/qxl_image.c +++ b/src/qxl_image.c @@ -31,6 +31,9 @@ #include string.h #include assert.h #include stdlib.h + +#include spice/macros.h + #include qxl.h #include murmurhash3.h -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH xspice 1/2] Xspice: cleanup Xorg process on SIGTERM
Signed-off-by: Alon Levy al...@redhat.com --- scripts/Xspice | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/Xspice b/scripts/Xspice index a4eb647..17439a1 100755 --- a/scripts/Xspice +++ b/scripts/Xspice @@ -22,6 +22,7 @@ import sys import tempfile import atexit import time +import signal from subprocess import Popen, PIPE def which(x): @@ -154,7 +155,7 @@ if not args.xorg: cleanup_files = [] cleanup_processes = [] -def cleanup(): +def cleanup(*args): for f in cleanup_files: if os.path.isfile(f): os.remove(f) @@ -162,12 +163,14 @@ def cleanup(): p.kill() for p in cleanup_processes: p.wait() +del cleanup_processes[:] def launch(*args, **kw): p = Popen(*args, **kw) cleanup_processes.append(p) return p +signal.signal(signal.SIGTERM, cleanup) atexit.register(cleanup) if args.auto: -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH xspice 2/2] xspice: add tests for audio remoting
Signed-off-by: Alon Levy al...@redhat.com
---
tests/xspice_audio_test.py| 19 +++
tests/xspice_audio_test_helper.py | 19 +++
tests/xspice_util.py | 69 +++
3 files changed, 107 insertions(+)
create mode 100755 tests/xspice_audio_test.py
create mode 100755 tests/xspice_audio_test_helper.py
create mode 100755 tests/xspice_util.py
diff --git a/tests/xspice_audio_test.py b/tests/xspice_audio_test.py
new file mode 100755
index 000..455c1aa
--- /dev/null
+++ b/tests/xspice_audio_test.py
@@ -0,0 +1,19 @@
+#!/usr/bin/python
+
+from time import sleep
+from xspice_audio_test_helper import produce_audio
+from xspice_util import launch_xspice, launch_client
+
+def main():
+port = 8000
+xspice = launch_xspice(port)
+sleep(2)
+client = launch_client(port)
+sleep(1)
+produce_audio(xspice.audio_fifo_dir)
+sleep(2)
+client.kill()
+xspice.kill()
+
+if __name__ == '__main__':
+main()
diff --git a/tests/xspice_audio_test_helper.py
b/tests/xspice_audio_test_helper.py
new file mode 100755
index 000..fbe3a54
--- /dev/null
+++ b/tests/xspice_audio_test_helper.py
@@ -0,0 +1,19 @@
+#!/usr/bin/python
+# coding: utf-8
+import os
+import sys
+import struct
+from math import sin, pi
+
+def produce_audio(basedir):
+filename = os.path.join(basedir, 'testaudio')
+os.system(u'mkfifo %s' % filename)
+if not os.path.exists(basedir):
+print missing fifo dir %s % repr(basedir)
+f=open(filename,'w')
+singen = lambda f: lambda t: (int(min(32767, 32768*sin(t*f/1000.0*pi))),
int(min(32767, 32768*sin(t*f/1000.0*pi
+f.write(''.join( struct.pack('hh', *singen(40)(t)) for t in xrange(44100)
) )
+os.unlink(filename)
+
+if __name__ == '__main__':
+produce_audio(sys.argv[-1] if len(sys.argv) 1 else '/tmp/xspice-audio/')
diff --git a/tests/xspice_util.py b/tests/xspice_util.py
new file mode 100755
index 000..a2e8578
--- /dev/null
+++ b/tests/xspice_util.py
@@ -0,0 +1,69 @@
+#!/usr/bin/python
+
+import os
+from time import sleep
+import subprocess
+import atexit
+
+class Process(object):
+processes = []
+@classmethod
+def new(clazz, *args, **kw):
+clazz.processes.append(subprocess.Popen(*args, **kw))
+return clazz.processes[-1]
+
+@classmethod
+def atexit(clazz):
+for p in reversed(clazz.processes):
+print child %s % p.pid
+if False:
+slp = subprocess.Popen(['/usr/bin/sleep', '1'])
+print wait on %d % slp.pid
+slp.wait()
+if len(clazz.processes) == 0:
+return
+for p in reversed(clazz.processes):
+print kill %s % p.pid
+try:
+p.kill()
+except:
+pass
+if not any(p.poll() for p in clazz.processes):
+return
+sleep(1)
+for p in reversed(clazz.processes):
+if not p.poll():
+print terminate %s % p.pid
+try:
+p.terminate()
+except:
+pass
+
+atexit.register(Process.atexit)
+
+def which(prog):
+for path_element in os.environ['PATH'].split(':'):
+candidate = os.path.join(path_element, prog)
+if os.path.exists(candidate):
+return candidate
+return None
+
+client_executable = which('remote-viewer')
+if not client_executable:
+raise SystemExit('missing remote-viewer in path')
+
+def launch_xspice(port):
+basedir = '/tmp/xspice_test_audio'
+if not os.path.exists(basedir):
+os.mkdir(basedir)
+assert(os.path.exists(basedir))
+xspice = Process.new(['../scripts/Xspice', '--port', '8000', '--auto',
'--audio-fifo-dir', basedir, '--disable-ticketing', ':15.0'])
+xspice.audio_fifo_dir = basedir
+return xspice
+
+def launch_client(port):
+client = Process.new([client_executable, 'spice://localhost:%s' % port])
+return client
+
+if __name__ == '__main__':
+launch_xspice(port=8000)
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] Release 0.1.1
--- NEWS | 12 configure.ac | 2 +- 2 files changed, 13 insertions(+), 1 deletion(-) create mode 100644 NEWS diff --git a/NEWS b/NEWS new file mode 100644 index 000..4ece9fe --- /dev/null +++ b/NEWS @@ -0,0 +1,12 @@ +Major changes in 0.1.1 +== + +KMS support +DFPS available to guest driver too +Xspice audio agent support +GPL code removed (EDID) +Warnings squash +Bug fixes (numbers are Red Hat Bugzilla bug ids): + 883578 - remote-viewer gets frozen after migration of guest with video playback + 968931 - Crash in Xspice after closing tab with spice-html5 + 894421 - Small change in guests resolution results in wrong resolution diff --git a/configure.ac b/configure.ac index 6322d53..01377a4 100644 --- a/configure.ac +++ b/configure.ac @@ -23,7 +23,7 @@ # Initialize Autoconf AC_PREREQ([2.60]) AC_INIT([xf86-video-qxl], -[0.1.0], +[0.1.1], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [xf86-video-qxl]) AC_CONFIG_SRCDIR([Makefile.am]) -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH (pushed) xf86-video-qxl] fix make dist
Signed-off-by: Alon Levy al...@redhat.com --- src/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/Makefile.am b/src/Makefile.am index edc2f0b..4c4ae40 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -110,6 +110,7 @@ spiceqxl_drv_la_SOURCES = \ murmurhash3.h \ qxl_cursor.c\ dfps.c \ + dfps.h \ qxl_uxa.c \ qxl_ums_mode.c \ qxl_io.c\ -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [ANNOUNCE] xf86-video-qxl 0.1.1
I'm happy to announce a new xf86-video-qxl release, 0.1.1. Here is the list of
changes:
Major changes in 0.1.1
==
KMS support
DFPS available to guest driver too
Xspice audio agent support
GPL code removed (EDID)
Warnings squash
Bug fixes (numbers are Red Hat Bugzilla bug ids):
883578 - remote-viewer gets frozen after migration of guest with video playback
968931 - Crash in Xspice after closing tab with spice-html5
894421 - Small change in guests resolution results in wrong resolution
Adam Jackson (1):
Remove mibstore.h
Alon Levy (23):
spiceqxl_main_loop: fix use of watch after removal
fix a bunch of warnings - unused variables, labels, code
fix undefined symbol qxl_enter_vt_kms for XSPICE
xspice: support sending monitors config
xspice: zero memory on allocation, fix uninitialized use (valgrind
reported)
spiceqxl_inputs: expose buttons position api for agent usage
qxl_option_helpers: add required includes
xspice: add vdagent support
xspice: add uinput support to vdagent support
Xspice: use subprocess.Popen, nicer cleanup of files/processes
Xspice: correct doc string
Xspice: require display parameter, and set if earlier in environment
Xspice: vdagent{,d} launching support
qxl_get_formats: use surface enum, not bitmap (fixes clang warning)
spiceqxl_display: add noreturn attribute (silence clang warning)
uxa: use PIXMAN consts instead of PICT in some places (silence clang
warning)
Xspice: add --audio-fifo-dir
spiceqxl_audio: fix possible buffer overflow (clang)
qxl_image: fix build break once MIN/MAX switched to spice-protocol
Xspice: kill Xorg process on SIGTERM
xspice: add tests for audio remoting
Release 0.1.1
fix make dist
Andrew Eikum (1):
Implement sending audio to the client from a directory of FIFO queues
Cole Robinson (1):
qxl: Report actual module version
Dave Airlie (31):
qxl: split uxa related code into separate file
qxl: split user modesetting code and crtc code out.
qxl: move io functions to a separate file
qxl_mem: drop unused if 0 code.
qxl: move mem slots code to qxl_mem.c
qxl: move garbage collector + alloc into qxl_mem.c
qxl: move mspace setup to qxl_mem.c
uxa: port over tiled fill code from EXA
qxl: split surface struct out into its own header file.
qxl: pass qxl instead of surface cache to some functions
qxl_surface: move to using struct to avoid ordering issues with typedef.
qxl: fix memory leak on driver exit.
qxl: split common pre init code out from qxl pre init
qxl_edid: add missing config.h
qxl: pass surface struct instead of ids in drawable functions.
qxl: add direct pointer from qxl surface to qxl screen
qxl: abstract object allocation away from surface/image/cursor code
qxl: separate surface ums code out into separate file
qxl: fix build in koji
qxl: fix xspice build due to missing include.
qxl: use u64_to_pointer to avoid warnings when building on i686
qxl: drop pointless and wrong memset.
qxl: add KMS support v1.2
qxl/kms: recreate the host image upon resize
qxl: don't enable kms unless we can find qxl_drm.h
qxl: fix 32-bit mmaps
qxl: fix issue with resizing dev_image improperly
qxl: add uevent handler support
qxl: drop GPL code from qxl driver
qxl: fix broken cursor hotspot on KMS driver
fix build with --disable-kms
Jeremy White (33):
Change include paths to fix rare compilation issue.
Unify memory management for the primary screen.
Add a DeferredFPS option.
Shift the uxa function initialization to a separate function.
Add a deferred frames mode.
Implement copy with fbFill.
Implement prepare_copy using GC functions.
Enable the use of SpiceExitOnDisconnect so that Xspice can be configured
Establish a preferred default of 1024x768 correctly.
We're uploading a drawable from the primary surface, use it.
Initialize our update region at surface creation, avoids 0 size regions
Handle cache and surface options the same way we handle all options.
Add missing options to the example xorg.conf file.
Consolidate and document the missing parameters
Add a '--auto' flag to create a temporary xorg.conf file.
Enable the deferred-fps and exit-on-disconnect options
Add a --xsession option, to allow for an automatic start of an xsession
script
Add an example stanza for the FIFO dir logic.
More correctly signal that we only want the first head connected at start.
Eliminate gcc warning on duplicate use of ARRAY_SIZE by Xorg.
Removed unused local variables
Document a meaningful warning.
Eliminate a printf format warning on 32 bit systems.
Actually request the forcibly inline functions
[Spice-devel] [PATCH v3 spice-gtk 2/2] channel-cursor: mono cursors edge highlighting
Fix 998529, mono (invert) cursors not visible on a black background, by doing
simple edge detection on the cursor (this is done once when the cursor
is changed and then cached, cursors are 32x32 generally) and thus having
a cursor with contrast on both dark and light backgrounds.
When (if) GDK gets invert cursor support (wayland?) then we can just use
the cursor as is. Until then X doesn't provide any way I see of solving
this otherwise. The end result was tested with the I beam cursor that
the original bug was referring to (run putty on a windows 7 vm) and
looks ok to me.
Moving the core function to spice-util for testing.
---
gtk/channel-cursor.c | 64 +++
gtk/spice-util-priv.h | 2 +
gtk/spice-util.c | 112 +++
tests/util.c | 117 ++
4 files changed, 237 insertions(+), 58 deletions(-)
diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c
index 66e91df..e056b30 100644
--- a/gtk/channel-cursor.c
+++ b/gtk/channel-cursor.c
@@ -277,70 +277,18 @@ static void print_cursor(display_cursor *cursor, const
guint8 *data)
static void mono_cursor(display_cursor *cursor, const guint8 *data)
{
+int bpl = (cursor-hdr.width + 7) / 8;
const guint8 *xor, *and;
guint8 *dest;
-int bpl, x, y, bit;
+dest = (uint8_t *)cursor-data;
-bpl = (cursor-hdr.width + 7) / 8;
-and = data;
-xor = and + bpl * cursor-hdr.height;
-dest = (uint8_t *)cursor-data;
#ifdef DEBUG_CURSOR
print_cursor(cursor, data);
#endif
-for (y = 0; y cursor-hdr.height; y++) {
-bit = 0x80;
-for (x = 0; x cursor-hdr.width; x++, dest += 4) {
-if (and[x/8] bit) {
-if (xor[x/8] bit) {
-/*
- * flip - unsupported by x11, since XCreatePixmapCursor
has
- * no invert functionality, only a mask, shape, background
and
- * foreground colors. Use this checkerboard hack to get
some
- * contrast for cursors in the guest that relied on invert
for
- * the same contrast.
- */
-if ((x ^ y) 1) {
-dest[0] = 0xff;
-dest[1] = 0xff;
-dest[2] = 0xff;
-dest[3] = 0xff;
-} else {
-dest[0] = 0x00;
-dest[1] = 0x00;
-dest[2] = 0x00;
-dest[3] = 0x00;
-}
-} else {
-/* unchanged - transparent */
-dest[0] = 0x00;
-dest[1] = 0x00;
-dest[2] = 0x00;
-dest[3] = 0x00;
-}
-} else {
-if (xor[x/8] bit) {
-/* set - white */
-dest[0] = 0xff;
-dest[1] = 0xff;
-dest[2] = 0xff;
-dest[3] = 0xff;
-} else {
-/* clear - black */
-dest[0] = 0x00;
-dest[1] = 0x00;
-dest[2] = 0x00;
-dest[3] = 0xff;
-}
-}
-bit = 1;
-if (bit == 0) {
-bit = 0x80;
-}
-}
-and += bpl;
-xor += bpl;
-}
+and = data;
+xor = and + bpl * cursor-hdr.height;
+spice_mono_edge_highlight(cursor-hdr.width, cursor-hdr.height,
+ and, xor, dest);
}
static guint8 get_pix_mask(const guint8 *data, gint offset, gint pix_index)
diff --git a/gtk/spice-util-priv.h b/gtk/spice-util-priv.h
index cc559dc..7f0df3c 100644
--- a/gtk/spice-util-priv.h
+++ b/gtk/spice-util-priv.h
@@ -31,6 +31,8 @@ const gchar* spice_yes_no(gboolean value);
guint16 spice_make_scancode(guint scancode, gboolean release);
gchar* spice_unix2dos(const gchar *str, gssize len, GError **error);
gchar* spice_dos2unix(const gchar *str, gssize len, GError **error);
+void spice_mono_edge_highlight(unsigned width, unsigned hight,
+ const guint8 *and, const guint8 *xor, guint8
*dest);
#if GLIB_CHECK_VERSION(2,32,0)
#define STATIC_MUTEXGMutex
diff --git a/gtk/spice-util.c b/gtk/spice-util.c
index 21dfced..8810a19 100644
--- a/gtk/spice-util.c
+++ b/gtk/spice-util.c
@@ -20,6 +20,7 @@
# include config.h
#endif
+#include stdbool.h
#include stdlib.h
#include string.h
#include glib.h
@@ -374,3 +375,114 @@ gchar* spice_unix2dos(const gchar *str, gssize len,
GError **error)
NEWLINE_TYPE_CR_LF,
error);
}
+
+static bool buf_is_ones(unsigned size, const guint8 *data)
+{
+int i;
+
+for (i = 0 ; i size; ++i) {
+if
[Spice-devel] [PATCH] channel-cursor: mono cursors edge highlighting
Fix 998529, mono (invert) cursors not visible on a black background, by doing
simple edge detection on the cursor (this is done once when the cursor
is changed and then cached, cursors are 32x32 generally) and thus having
a cursor with contrast on both dark and light backgrounds.
When (if) GDK gets invert cursor support (wayland?) then we can just use
the cursor as is. Until then X doesn't provide any way I see of solving
this otherwise. The end result was tested with the I beam cursor that
the original bug was referring to (run putty on a windows 7 vm) and
looks ok to me.
---
gtk/channel-cursor.c | 78 ++--
1 file changed, 75 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c
index d1d2c34..322afd9 100644
--- a/gtk/channel-cursor.c
+++ b/gtk/channel-cursor.c
@@ -246,19 +246,90 @@ static void do_emit_main_context(GObject *object, int
signum, gpointer params)
/* -- */
-static void mono_cursor(display_cursor *cursor, const guint8 *data)
+#ifdef DEBUG_CURSOR
+static void print_cursor(display_cursor *cursor, const guint8 *data)
{
+int x, y, bpl;
const guint8 *xor, *and;
+
+bpl = (cursor-hdr.width + 7) / 8;
+and = data;
+xor = and + bpl * cursor-hdr.height;
+
+printf(data (%d x %d):\n, cursor-hdr.width, cursor-hdr.height);
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; x++) {
+printf(%02X, and[x]);
+}
+and += bpl;
+printf(\n);
+}
+printf(xor:\n);
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; ++x) {
+printf(%02X, xor[x]);
+}
+xor += bpl;
+printf(\n);
+}
+}
+#endif
+
+static bool cursor_xor_pixel(const guint8 *xor, int bpl, int x, int y)
+{
+return (xor[bpl * y + (x / 8)] (0x80 (x % 8))) 0;
+}
+
+static guint8 cursor_is_xor_edge(display_cursor *cursor, const guint8 *xor,
int bpl, int x, int y)
+{
+if (x == 0 || x == cursor-hdr.width -1 || y == 0 || y ==
cursor-hdr.height - 1) {
+return 0;
+}
+#define P(x, y) cursor_xor_pixel(xor, bpl, x, y)
+return !P(x, y) (P(x - 1, y + 1) || P(x, y + 1) || P(x + 1, y + 1) ||
+P(x - 1, y) ||P(x + 1, y) ||
+P(x - 1, y - 1) || P(x, y - 1) || P(x + 1, y - 1));
+#undef P
+}
+
+static bool cursor_is_and_ones(display_cursor *cursor, const guint8 *data)
+{
+int x, y, bpl;
+
+bpl = (cursor-hdr.width + 7) / 8;
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; ++x) {
+if (data[x] != 0xff) {
+return false;
+}
+}
+data += bpl;
+}
+return true;
+}
+
+static void mono_cursor(SpiceChannel *channel, display_cursor *cursor, const
guint8 *data)
+{
+const guint8 *xor, *xor_base, *and;
guint8 *dest;
int bpl, x, y, bit;
+bool and_ones = cursor_is_and_ones(cursor, data);
bpl = (cursor-hdr.width + 7) / 8;
and = data;
-xor = and + bpl * cursor-hdr.height;
+xor_base = xor = and + bpl * cursor-hdr.height;
dest = (uint8_t *)cursor-data;
+#ifdef DEBUG_CURSOR
+print_cursor(cursor, data);
+#endif
for (y = 0; y cursor-hdr.height; y++) {
bit = 0x80;
for (x = 0; x cursor-hdr.width; x++, dest += 4) {
+if (cursor_is_xor_edge(cursor, xor_base, bpl, x, y) and_ones) {
+dest[0] = dest[1] = dest[2] = 0x00;
+dest[3] = 0xff;
+goto next_bit;
+}
if (and[x/8] bit) {
if (xor[x/8] bit) {
/*
@@ -301,6 +372,7 @@ static void mono_cursor(display_cursor *cursor, const
guint8 *data)
dest[3] = 0xff;
}
}
+next_bit:
bit = 1;
if (bit == 0) {
bit = 0x80;
@@ -395,7 +467,7 @@ static display_cursor *set_cursor(SpiceChannel *channel,
SpiceCursor *scursor)
switch (hdr-type) {
case SPICE_CURSOR_TYPE_MONO:
-mono_cursor(cursor, data);
+mono_cursor(channel, cursor, data);
break;
case SPICE_CURSOR_TYPE_ALPHA:
memcpy(cursor-data, data, size);
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] channel-cursor: mono cursors edge highlighting
On 10/18/2013 02:30 PM, Alon Levy wrote:
Please ignore, I'll send a new version.
Fix 998529, mono (invert) cursors not visible on a black background, by doing
simple edge detection on the cursor (this is done once when the cursor
is changed and then cached, cursors are 32x32 generally) and thus having
a cursor with contrast on both dark and light backgrounds.
When (if) GDK gets invert cursor support (wayland?) then we can just use
the cursor as is. Until then X doesn't provide any way I see of solving
this otherwise. The end result was tested with the I beam cursor that
the original bug was referring to (run putty on a windows 7 vm) and
looks ok to me.
---
gtk/channel-cursor.c | 78 ++--
1 file changed, 75 insertions(+), 3 deletions(-)
diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c
index d1d2c34..322afd9 100644
--- a/gtk/channel-cursor.c
+++ b/gtk/channel-cursor.c
@@ -246,19 +246,90 @@ static void do_emit_main_context(GObject *object, int
signum, gpointer params)
/* -- */
-static void mono_cursor(display_cursor *cursor, const guint8 *data)
+#ifdef DEBUG_CURSOR
+static void print_cursor(display_cursor *cursor, const guint8 *data)
{
+int x, y, bpl;
const guint8 *xor, *and;
+
+bpl = (cursor-hdr.width + 7) / 8;
+and = data;
+xor = and + bpl * cursor-hdr.height;
+
+printf(data (%d x %d):\n, cursor-hdr.width, cursor-hdr.height);
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; x++) {
+printf(%02X, and[x]);
+}
+and += bpl;
+printf(\n);
+}
+printf(xor:\n);
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; ++x) {
+printf(%02X, xor[x]);
+}
+xor += bpl;
+printf(\n);
+}
+}
+#endif
+
+static bool cursor_xor_pixel(const guint8 *xor, int bpl, int x, int y)
+{
+return (xor[bpl * y + (x / 8)] (0x80 (x % 8))) 0;
+}
+
+static guint8 cursor_is_xor_edge(display_cursor *cursor, const guint8 *xor,
int bpl, int x, int y)
+{
+if (x == 0 || x == cursor-hdr.width -1 || y == 0 || y ==
cursor-hdr.height - 1) {
+return 0;
+}
+#define P(x, y) cursor_xor_pixel(xor, bpl, x, y)
+return !P(x, y) (P(x - 1, y + 1) || P(x, y + 1) || P(x + 1, y + 1) ||
+P(x - 1, y) ||P(x + 1, y) ||
+P(x - 1, y - 1) || P(x, y - 1) || P(x + 1, y - 1));
+#undef P
+}
+
+static bool cursor_is_and_ones(display_cursor *cursor, const guint8 *data)
+{
+int x, y, bpl;
+
+bpl = (cursor-hdr.width + 7) / 8;
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; ++x) {
+if (data[x] != 0xff) {
+return false;
+}
+}
+data += bpl;
+}
+return true;
+}
+
+static void mono_cursor(SpiceChannel *channel, display_cursor *cursor, const
guint8 *data)
+{
+const guint8 *xor, *xor_base, *and;
guint8 *dest;
int bpl, x, y, bit;
+bool and_ones = cursor_is_and_ones(cursor, data);
bpl = (cursor-hdr.width + 7) / 8;
and = data;
-xor = and + bpl * cursor-hdr.height;
+xor_base = xor = and + bpl * cursor-hdr.height;
dest = (uint8_t *)cursor-data;
+#ifdef DEBUG_CURSOR
+print_cursor(cursor, data);
+#endif
for (y = 0; y cursor-hdr.height; y++) {
bit = 0x80;
for (x = 0; x cursor-hdr.width; x++, dest += 4) {
+if (cursor_is_xor_edge(cursor, xor_base, bpl, x, y) and_ones) {
+dest[0] = dest[1] = dest[2] = 0x00;
+dest[3] = 0xff;
+goto next_bit;
+}
if (and[x/8] bit) {
if (xor[x/8] bit) {
/*
@@ -301,6 +372,7 @@ static void mono_cursor(display_cursor *cursor, const
guint8 *data)
dest[3] = 0xff;
}
}
+next_bit:
bit = 1;
if (bit == 0) {
bit = 0x80;
@@ -395,7 +467,7 @@ static display_cursor *set_cursor(SpiceChannel *channel,
SpiceCursor *scursor)
switch (hdr-type) {
case SPICE_CURSOR_TYPE_MONO:
-mono_cursor(cursor, data);
+mono_cursor(channel, cursor, data);
break;
case SPICE_CURSOR_TYPE_ALPHA:
memcpy(cursor-data, data, size);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH v2 spice-gtk 1/2] cursor-channel.c: add cursor print function for debugging only (ifdefed)
---
gtk/channel-cursor.c | 32
1 file changed, 32 insertions(+)
diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c
index d1d2c34..66e91df 100644
--- a/gtk/channel-cursor.c
+++ b/gtk/channel-cursor.c
@@ -246,6 +246,35 @@ static void do_emit_main_context(GObject *object, int
signum, gpointer params)
/* -- */
+#ifdef DEBUG_CURSOR
+static void print_cursor(display_cursor *cursor, const guint8 *data)
+{
+int x, y, bpl;
+const guint8 *xor, *and;
+
+bpl = (cursor-hdr.width + 7) / 8;
+and = data;
+xor = and + bpl * cursor-hdr.height;
+
+printf(data (%d x %d):\n, cursor-hdr.width, cursor-hdr.height);
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; x++) {
+printf(%02X, and[x]);
+}
+and += bpl;
+printf(\n);
+}
+printf(xor:\n);
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; ++x) {
+printf(%02X, xor[x]);
+}
+xor += bpl;
+printf(\n);
+}
+}
+#endif
+
static void mono_cursor(display_cursor *cursor, const guint8 *data)
{
const guint8 *xor, *and;
@@ -256,6 +285,9 @@ static void mono_cursor(display_cursor *cursor, const
guint8 *data)
and = data;
xor = and + bpl * cursor-hdr.height;
dest = (uint8_t *)cursor-data;
+#ifdef DEBUG_CURSOR
+print_cursor(cursor, data);
+#endif
for (y = 0; y cursor-hdr.height; y++) {
bit = 0x80;
for (x = 0; x cursor-hdr.width; x++, dest += 4) {
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH v2 spice-gtk 2/2] channel-cursor: mono cursors edge highlighting
Fix 998529, mono (invert) cursors not visible on a black background, by doing
simple edge detection on the cursor (this is done once when the cursor
is changed and then cached, cursors are 32x32 generally) and thus having
a cursor with contrast on both dark and light backgrounds.
When (if) GDK gets invert cursor support (wayland?) then we can just use
the cursor as is. Until then X doesn't provide any way I see of solving
this otherwise. The end result was tested with the I beam cursor that
the original bug was referring to (run putty on a windows 7 vm) and
looks ok to me.
---
gtk/channel-cursor.c | 86
1 file changed, 66 insertions(+), 20 deletions(-)
diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c
index 66e91df..2c48d37 100644
--- a/gtk/channel-cursor.c
+++ b/gtk/channel-cursor.c
@@ -275,15 +275,67 @@ static void print_cursor(display_cursor *cursor, const
guint8 *data)
}
#endif
+static bool cursor_xor_pixel(const guint8 *xor, int bpl, int x, int y)
+{
+return (xor[bpl * y + (x / 8)] (0x80 (x % 8))) 0;
+}
+
+static guint8 cursor_is_xor_edge(display_cursor *cursor, const guint8 *xor,
int bpl, int x, int y)
+{
+if (x == 0 || x == cursor-hdr.width -1 || y == 0 || y ==
cursor-hdr.height - 1) {
+return 0;
+}
+#define P(x, y) cursor_xor_pixel(xor, bpl, x, y)
+return !P(x, y) (P(x - 1, y + 1) || P(x, y + 1) || P(x + 1, y + 1) ||
+P(x - 1, y) ||P(x + 1, y) ||
+P(x - 1, y - 1) || P(x, y - 1) || P(x + 1, y - 1));
+#undef P
+}
+
+static bool cursor_is_and_ones(display_cursor *cursor, const guint8 *data)
+{
+int x, y, bpl;
+
+bpl = (cursor-hdr.width + 7) / 8;
+for (y = 0 ; y cursor-hdr.height; ++y) {
+for (x = 0 ; x cursor-hdr.width / 8; ++x) {
+if (data[x] != 0xff) {
+return false;
+}
+}
+data += bpl;
+}
+return true;
+}
+
+/* Mono cursors have two places, and and xor. If a bit is 1 in both, it
+ * means invertion of the corresponding pixel in the display. Since X11 (and
+ * gdk) doesn't do invertion, instead we do edge detection and turn the
+ * sorrounding edge pixels black, and the invert-me pixels white. To
+ * illustrate:
+ *
+ * and xor dest RGB (1=0xff, 0=0x00)
+ *
+ *dest alpha (1=0xff, 0=0x00)
+ *
+ * 1 0 0 0
+ * 1 0 0 01110
+ * 1 00100 = 00100 01110
+ * 1 00100 00100 01110
+ * 1 0 0 01110
+ * 1 0 0 0
+ *
+ */
static void mono_cursor(display_cursor *cursor, const guint8 *data)
{
-const guint8 *xor, *and;
+const guint8 *xor, *xor_base, *and;
guint8 *dest;
int bpl, x, y, bit;
+bool and_ones = cursor_is_and_ones(cursor, data);
bpl = (cursor-hdr.width + 7) / 8;
and = data;
-xor = and + bpl * cursor-hdr.height;
+xor_base = xor = and + bpl * cursor-hdr.height;
dest = (uint8_t *)cursor-data;
#ifdef DEBUG_CURSOR
print_cursor(cursor, data);
@@ -291,26 +343,19 @@ static void mono_cursor(display_cursor *cursor, const
guint8 *data)
for (y = 0; y cursor-hdr.height; y++) {
bit = 0x80;
for (x = 0; x cursor-hdr.width; x++, dest += 4) {
+if (cursor_is_xor_edge(cursor, xor_base, bpl, x, y) and_ones) {
+dest[0] = 0x00;
+dest[1] = 0x00;
+dest[2] = 0x00;
+dest[3] = 0xff;
+goto next_bit;
+}
if (and[x/8] bit) {
if (xor[x/8] bit) {
-/*
- * flip - unsupported by x11, since XCreatePixmapCursor
has
- * no invert functionality, only a mask, shape, background
and
- * foreground colors. Use this checkerboard hack to get
some
- * contrast for cursors in the guest that relied on invert
for
- * the same contrast.
- */
-if ((x ^ y) 1) {
-dest[0] = 0xff;
-dest[1] = 0xff;
-dest[2] = 0xff;
-dest[3] = 0xff;
-} else {
-dest[0] = 0x00;
-dest[1] = 0x00;
-dest[2] = 0x00;
-dest[3] = 0x00;
-}
+dest[0] = 0xff;
+dest[1] = 0xff;
+dest[2] = 0xff;
+dest[3] = 0xff;
} else {
/* unchanged - transparent */
dest[0] = 0x00;
@@ -333,6 +378,7 @@ static void mono_cursor(display_cursor *cursor, const
guint8 *data)
dest[3] = 0xff;
}
}
+next_bit:
bit = 1;
if
Re: [Spice-devel] [patch 2/3] spice-server: add push_utf8 callback to input channel
On 10/16/2013 02:04 PM, diet...@proxmox.com wrote: For next time: can you send the patches inline? it is easier to respond to then to mails with attachments. You should increment SPICE_INTERFACE_KEYBOARD_MINOR as well to allow users (qemu / spiceterm / xspice etc.) to compile to both old and new versions easily (assuming they decide perhaps sometime to use the new functionality). ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk] display: blank surface on creation
On 10/16/2013 10:08 PM, Marc-André Lureau wrote:
In theory, zero-ing the surface shouldn't be necessary, as only
invalidated/painted region should be shown. However, this results in
less artifacts on resolution changes (probably some regions are painted,
but with masks, blend, copy etc), in particular on console after VM
reboot.
ACK. On guest reboot / resolution change (reboot is just a special case
because of entering vga mode, which is from server pov a special case of
resolution change) the server sends a new surface, which is not blank
(not all zeros). That is an emulation error since I don't believe it
happens in real life, but it's way easier to fix it here. so ack.
---
gtk/channel-display.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index a57453f..96b311d 100644
--- a/gtk/channel-display.c
+++ b/gtk/channel-display.c
@@ -723,7 +723,11 @@ static int create_canvas(SpiceChannel *channel,
display_surface *surface)
}
if (surface-shmid == -1) {
-surface-data = spice_malloc(surface-size);
+/* in theory, zero-ing the surface shouldn't be necessary, as
+ only invalidated/painted region should be shown however,
+ this shows less artifact on resolution changes (probably
+ some regions are painted, but with masks etc) */
+surface-data = g_malloc0(surface-size);
}
g_return_val_if_fail(c-glz_window, 0);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH xf86-video-qxl 1/5] qxl_get_formats: use surface enum, not bitmap (fixes clang warning)
Signed-off-by: Alon Levy al...@redhat.com
---
src/qxl.h | 2 +-
src/qxl_kms.c | 2 +-
src/qxl_surface.c | 5 +++--
src/qxl_surface_ums.c | 2 +-
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/qxl.h b/src/qxl.h
index 52e92e9..c699c58 100644
--- a/src/qxl.h
+++ b/src/qxl.h
@@ -607,7 +607,7 @@ Bool qxl_enter_vt_kms (VT_FUNC_ARGS_DECL);
void qxl_leave_vt_kms (VT_FUNC_ARGS_DECL);
void qxl_set_screen_pixmap_header (ScreenPtr pScreen);
Bool qxl_resize_primary_to_virtual (qxl_screen_t *qxl);
-void qxl_get_formats (int bpp, SpiceBitmapFmt *format, pixman_format_code_t
*pformat);
+void qxl_get_formats (int bpp, SpiceSurfaceFmt *format, pixman_format_code_t
*pformat);
#ifdef XF86DRM_MODE
Bool qxl_pre_init_kms(ScrnInfoPtr pScrn, int flags);
diff --git a/src/qxl_kms.c b/src/qxl_kms.c
index 6c5b427..d6dfcee 100644
--- a/src/qxl_kms.c
+++ b/src/qxl_kms.c
@@ -593,7 +593,7 @@ qxl_kms_surface_create(qxl_screen_t *qxl,
int height,
int bpp)
{
-SpiceBitmapFmt format;
+SpiceSurfaceFmt format;
qxl_surface_t *surface;
int stride;
struct qxl_kms_bo *bo;
diff --git a/src/qxl_surface.c b/src/qxl_surface.c
index 685d09f..1075eae 100644
--- a/src/qxl_surface.c
+++ b/src/qxl_surface.c
@@ -804,7 +804,7 @@ qxl_surface_put_image (qxl_surface_t *dest,
}
void
-qxl_get_formats (int bpp, SpiceBitmapFmt *format, pixman_format_code_t
*pformat)
+qxl_get_formats (int bpp, SpiceSurfaceFmt *format, pixman_format_code_t
*pformat)
{
switch (bpp)
{
@@ -829,7 +829,8 @@ qxl_get_formats (int bpp, SpiceBitmapFmt *format,
pixman_format_code_t *pformat)
break;
default:
- *format = *pformat = -1;
+ *format = -1;
+ *pformat = -1;
break;
}
}
diff --git a/src/qxl_surface_ums.c b/src/qxl_surface_ums.c
index 6839372..2c16ede 100644
--- a/src/qxl_surface_ums.c
+++ b/src/qxl_surface_ums.c
@@ -430,7 +430,7 @@ surface_send_create (surface_cache_t *cache,
int height,
int bpp)
{
-SpiceBitmapFmt format;
+SpiceSurfaceFmt format;
pixman_format_code_t pformat;
struct QXLSurfaceCmd *cmd;
int stride;
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH xf86-video-qxl 2/5] spiceqxl_display: add noreturn attribute (silence clang warning)
Signed-off-by: Alon Levy al...@redhat.com
---
src/spiceqxl_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/spiceqxl_display.c b/src/spiceqxl_display.c
index 9c42d84..3acbb1c 100644
--- a/src/spiceqxl_display.c
+++ b/src/spiceqxl_display.c
@@ -287,7 +287,8 @@ static int interface_req_cursor_notification(QXLInstance
*sin)
}
/* called from spice server thread context */
-static void interface_notify_update(QXLInstance *sin, uint32_t update_id)
+static void __attribute__ ((__noreturn__))
+interface_notify_update(QXLInstance *sin, uint32_t update_id)
{
fprintf(stderr, %s: abort()\n, __FUNCTION__);
abort();
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Vdagent not working on xen linux hvm DomUs
On 10/14/2013 05:52 PM, Fabio Fantoni wrote: I have added vdagent support on libxl for hvm domUs using upstream qemu. On windows domUs it is working without problems found in over one year that I'm using it. On linux domUs is not working, it seems to be a problem on the kernel side and/or linux vdagent services. The domU parameters are the same on both linux and windows domUs and below you can be find some details on dom0 if needed: http://lists.xen.org/archives/html/xen-devel/2013-10/msg0.html On my latest test with Fedora19 domU: - on install one month ago there was this log: /var/log/spice-vdagent.log (nomore now) spice-vdagent[1398]: err: Missing virtio device '/dev/virtio-ports/com.redhat.spice.0': No such file or directory This seems to be the error. You are missing the virtio device. Does the domU have the virtio-serial module loaded (or compiled in)? does the vm have the appropriate corresponding options in xen for creating that virtio pci device and the virtio serial port on top of it, with that name? - spice-vdagent package is installed - /dev/virtio-ports is missed - lspci shows virtio console with virtio-pci driver in use virtio console is something else. virtio-serial replaced it iirc, and is backward compatible, but you don't need a console. I'm not familiar with Xen so I can't help in this. But this is your problem - don't bother checking any thing else until you have this device node present in the guest. Tried to check service: # systemctl status spice-vdagentd spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; enabled) Active: inactive (dead) # systemctl start spice-vdagentd # systemctl status spice-vdagentd spice-vdagentd.service - Agent daemon for Spice guests Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; enabled) Active: active (running) since lun 2013-10-14 16:32:52 CEST; 6s ago Process: 1723 ExecStart=/usr/sbin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS (code=exited, status=0/SUCCESS) Process: 1720 ExecStartPre=/bin/rm -f /var/run/spice-vdagentd/spice-vdagent-sock (code=exited, status=0/SUCCESS) Main PID: 1725 (spice-vdagentd) CGroup: name=systemd:/system/spice-vdagentd.service ââ1725 /usr/sbin/spice-vdagentd On /var/log/messages: ... Oct 14 16:32:52 localhost systemd[1]: Starting Agent daemon for Spice guests... Oct 14 16:32:52 localhost systemd[1]: PID file /var/run/spice-vdagentd/spice-vdagentd.pid not readable (yet?) after start. Oct 14 16:32:52 localhost systemd[1]: Started Agent daemon for Spice guests. But vdagent is still not working. If you need more details and test tell me and I'll post them. Thanks for any reply. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Announcing spice-vdagent 0.15.0
On 10/14/2013 04:15 PM, Alon Levy wrote: Hi All, I'm happy to announce a new release of the spice Linux agent, the first version with Xspice support. Changes in spice-vdagent-0.15.0: * Xspice support * Release clipboard on client disconnect if owned by client (rhbz#1003977) * Turn some error messages into debugging messages (rhbz#918310) * Not having the virtio channel is not an error; instead silently do nothing You can download source tarbals here: http://spice-space.org/download.html This release is signed with my GPG key: FF45 BD20 24DD AB0C 3A21 FAF8 6485 B762 E6E8 F5EE http://spice-space.org/download/releases/spice-vdagent-0.15.0.tar.bz2.sign http://spice-space.org/download/releases/spice-vdagent-0.15.0.tar.bz2 File size: 123527 Regards, Alon ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 1/2] vdagent-virtio-port: no need to log opening the port as a socket
---
src/vdagent-virtio-port.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/vdagent-virtio-port.c b/src/vdagent-virtio-port.c
index a5da35f..b04d55b 100644
--- a/src/vdagent-virtio-port.c
+++ b/src/vdagent-virtio-port.c
@@ -91,7 +91,6 @@ struct vdagent_virtio_port *vdagent_virtio_port_create(const
char *portname,
vport-fd = open(portname, O_RDWR);
if (vport-fd == -1) {
-syslog(LOG_INFO, open %s: %m; trying as socket, portname);
vport-fd = socket(PF_UNIX, SOCK_STREAM, 0);
if (vport-fd == -1) {
goto error;
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 2/2] Prepare for release 0.15.0
--- ChangeLog| 7 +++ configure.ac | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 99508f9..4138359 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +spice-vdagent-0.15.0 + +* Xspice support +* Release clipboard on client disconnect if owned by client (rhbz#1003977) +* Turn some error messages into debugging messages (rhbz#918310) +* Not having the virtio channel is not an error; instead silently do nothing + spice-vdagent-0.14.0 * More multi-monitor and arbritary resolution support bugfixes diff --git a/configure.ac b/configure.ac index a1ce6c0..79905a8 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ(2.59) -AC_INIT([spice-vdagent], [0.14.0]) +AC_INIT([spice-vdagent], [0.15.0]) AC_CONFIG_SRCDIR([configure.ac]) AM_CONFIG_HEADER([src/config.h]) -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [xf86-video] Handle a missed case where lack of kms doesn't work with XSpice.
On 10/01/2013 10:02 PM, Jeremy White wrote:
Ack
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
src/qxl_driver.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index ac5408e..515704b 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -1214,10 +1214,12 @@ qxl_init_scrn (ScrnInfoPtr pScrn, Bool kms)
pScrn-name = driver_name;
if (kms) {
+#ifdef XF86DRM_MODE
pScrn-PreInit = qxl_pre_init_kms;
pScrn-ScreenInit = qxl_screen_init_kms;
pScrn-EnterVT = qxl_enter_vt_kms;
pScrn-LeaveVT = qxl_leave_vt_kms;
+#endif
} else {
pScrn-PreInit = qxl_pre_init;
pScrn-ScreenInit = qxl_screen_init;
@@ -1260,7 +1262,7 @@ static Bool qxl_kernel_mode_enabled(ScrnInfoPtr pScrn,
struct pci_device *pci_de
return TRUE;
}
#else
-#define radeon_kernel_mode_enabled(x, y) FALSE
+#define qxl_kernel_mode_enabled(x, y) FALSE
#endif
#ifdef XSPICE
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 4/4] gl: use glCopyPixels()
On 09/24/2013 02:47 PM, Marc-André Lureau wrote:
I don't see why the fallback method should be the default.
glCopyTexImage2D and glCopyPixels are equally broken with current Intel
mesa/drivers (I'll be filing a bug). But sw rendering is correct.
---
common/glc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/glc.c b/common/glc.c
index 91b295c..c1795de 100644
--- a/common/glc.c
+++ b/common/glc.c
@@ -1263,7 +1263,7 @@ void glc_copy_pixels(GLCCtx glc, int x_dest, int y_dest,
int x_src, int y_src, i
int recreate = 0;
spice_assert(ctx);
-#ifdef USE_COPY_PIXELS
+#if 1 /* USE_COPY_PIXELS */
Why not kill the deadcode?
start_draw(ctx);
if (ctx-pat) {
glDisable(GL_TEXTURE_2D);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 08/11] spicec: add sw canvas diff check
On 09/24/2013 02:42 PM, Marc-André Lureau wrote:
Looks good, but can you explain why you disable diff check for fill, text?
---
client/display_channel.cpp | 88 +-
client/display_channel.h | 2 ++
client/red_pixmap.h| 19 ++
client/utils.h | 3 ++
4 files changed, 88 insertions(+), 24 deletions(-)
diff --git a/client/display_channel.cpp b/client/display_channel.cpp
index 49a4c6a..c9ce3d8 100644
--- a/client/display_channel.cpp
+++ b/client/display_channel.cpp
@@ -611,6 +611,7 @@ DisplayChannel::DisplayChannel(RedClient client, uint32_t
id,
#endif
, _interrupt_update (*this)
, _mig_wait_primary (false)
+, _check_diff (getenv(CHECKDIFF) != NULL)
{
DisplayHandler* handler =
static_castDisplayHandler*(get_message_handler());
@@ -1276,6 +1277,22 @@ void DisplayChannel::create_canvas(int surface_id, const std::vectorint canva
if (i == canvas_types.size()) {
THROW(create canvas failed);
}
+
+try {
+if (!_check_diff)
+return;
+
+SCanvas *canvas = new SCanvas(surface_id == 0, width, height, format,
+ screen()-get_window(),
+ _pixmap_cache, _palette_cache,
_glz_window,
+ _surfaces_cache);
+_swsurfaces_cache[surface_id] = canvas;
+if (surface_id == 0) {
+LOG_INFO(display %d: check sw, get_id());
+}
+} catch (...) {
+spice_warn_if_reached();
+}
}
void DisplayChannel::handle_mode(RedPeer::InMessage* message)
@@ -1620,29 +1637,52 @@ void
DisplayChannel::handle_surface_destroy(RedPeer::InMessage* message)
}
}
-#define PRE_DRAW
-#define POST_DRAW
+#define DRAW(type, can_diff) { \
+canvas-draw_##type(*type, message-size());\
+if (type-base.surface_id == 0) { \
+invalidate(type-base.box, false); \
+} \
+if ((can_diff) _check_diff) {\
+Canvas *swcanvas = _swsurfaces_cache[type-base.surface_id];\
+swcanvas-draw_##type(*type, message-size()); \
+check_diff(swcanvas, canvas, type-base.box); \
+} \
+}
+
+#include red_pixmap_sw.h
+
+void check_diff(Canvas *a, Canvas *b, const SpiceRect rect)
+{
+QRegion region;
+RedPixmapSw *ap = new RedPixmapSw(rect.right, rect.bottom,
RedDrawable::RGB32, true, 0);
+RedPixmapSw *bp = new RedPixmapSw(rect.right, rect.bottom,
RedDrawable::RGB32, true, 0);
+
+region_init(region);
+region_add(region, rect);
+a-copy_pixels(region, *ap);
+b-copy_pixels(region, *bp);
+ap-equal(*bp, rect);
-#define DRAW(type) {\
-PRE_DRAW; \
-canvas-draw_##type(*type, message-size());\
-POST_DRAW; \
-if (type-base.surface_id == 0) { \
-invalidate(type-base.box, false); \
-} \
+delete ap;
+delete bp;
}
void DisplayChannel::handle_copy_bits(RedPeer::InMessage* message)
{
Canvas *canvas;
SpiceMsgDisplayCopyBits* copy_bits =
(SpiceMsgDisplayCopyBits*)message-data();
-PRE_DRAW;
canvas = _surfaces_cache[copy_bits-base.surface_id];
+Canvas *swcanvas = _swsurfaces_cache[copy_bits-base.surface_id];
+
canvas-copy_bits(*copy_bits, message-size());
-POST_DRAW;
if (copy_bits-base.surface_id == 0) {
invalidate(copy_bits-base.box, false);
}
+
+if (_check_diff) {
+swcanvas-copy_bits(*copy_bits, message-size());
+check_diff(swcanvas, canvas, copy_bits-base.box);
+}
}
void DisplayChannel::handle_draw_fill(RedPeer::InMessage* message)
@@ -1650,7 +1690,7 @@ void DisplayChannel::handle_draw_fill(RedPeer::InMessage*
message)
Canvas *canvas;
SpiceMsgDisplayDrawFill* fill = (SpiceMsgDisplayDrawFill*)message-data();
canvas = _surfaces_cache[fill-base.surface_id];
-DRAW(fill);
+DRAW(fill, FALSE);
}
void DisplayChannel::handle_draw_opaque(RedPeer::InMessage* message)
@@ -1658,7 +1698,7 @@ void
DisplayChannel::handle_draw_opaque(RedPeer::InMessage* message)
Canvas *canvas;
SpiceMsgDisplayDrawOpaque* opaque =
(SpiceMsgDisplayDrawOpaque*)message-data();
canvas = _surfaces_cache[opaque-base.surface_id];
-DRAW(opaque);
+DRAW(opaque, TRUE);
}
void DisplayChannel::handle_draw_copy(RedPeer::InMessage* message)
@@ -1666,7 +1706,7 @@ void DisplayChannel::handle_draw_copy(RedPeer::InMessage*
message)
Re: [Spice-devel] [PATCH 11/11] spicec: refresh the display after display resize
On 09/24/2013 02:42 PM, Marc-André Lureau wrote:
This appears to be unrelated to the gl checks, same as the nograb fix
(excellent). Can you move both to the start of the patchset?
---
client/display_channel.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/client/display_channel.cpp b/client/display_channel.cpp
index c9ce3d8..47076ad 100644
--- a/client/display_channel.cpp
+++ b/client/display_channel.cpp
@@ -1278,6 +1278,10 @@ void DisplayChannel::create_canvas(int surface_id, const
std::vectorint canva
THROW(create canvas failed);
}
+// make sure to refresh the whole display
+SpiceRect rect = { 0, 0, width, height };
+invalidate(rect, true);
+
try {
if (!_check_diff)
return;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 00/11] fix spicec gl_fbo
On 09/24/2013 02:42 PM, Marc-André Lureau wrote: Hi, Please find a few patches fixing gl_fbo usage and glitches. spice-common needs to be updated too, with the opengl related fixes. (the submodule update will be done before, so ignore updates during review of these patches please) Looks good to me. My last comment was a question, so ack regardless of the answer. Marc-André Lureau (11): spicec: warn when throwing exception spicec: use standard opengl 3.0 framebuffer spicec: fix non-doublebuffer drawing spicec: use doublebuffer for opengl spicec: remove dead GL code spicec: add SPICE_NOGRAB spicec: do not abort if cache error spicec: add sw canvas diff check spicec: use pre/post copy spicec: disable stencil test with primary fbo spicec: refresh the display after display resize client/cache.hpp | 3 +- client/display_channel.cpp | 92 client/display_channel.h | 2 + client/red_gl_canvas.cpp | 2 + client/red_pixmap.h | 19 + client/red_window.h | 2 + client/screen.cpp| 1 + client/utils.h | 6 +++ client/x11/pixels_source_p.h | 1 + client/x11/platform.cpp | 3 +- client/x11/red_drawable.cpp | 13 --- client/x11/red_pixmap_gl.cpp | 85 client/x11/red_window.cpp| 50 +--- client/x11/red_window_p.h| 3 -- spice-common | 2 +- 15 files changed, 176 insertions(+), 108 deletions(-) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] mono cursor: increase contrast, better looking putty cursor (rhbz 998529)
Signed-off-by: Alon Levy al...@redhat.com
---
The previous fix is almost impossible to notice on putty, I'm assuming the
original values for the on/off pixels were taken from a different use case, but
so far since we do have a bug for putty and no bug for anything else I propose
we fix the putty case first.
gtk/channel-cursor.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gtk/channel-cursor.c b/gtk/channel-cursor.c
index bbfb3c9..d1d2c34 100644
--- a/gtk/channel-cursor.c
+++ b/gtk/channel-cursor.c
@@ -269,15 +269,15 @@ static void mono_cursor(display_cursor *cursor, const
guint8 *data)
* the same contrast.
*/
if ((x ^ y) 1) {
-dest[0] = 0x30;
-dest[1] = 0x30;
-dest[2] = 0x30;
-dest[3] = 0xc0;
+dest[0] = 0xff;
+dest[1] = 0xff;
+dest[2] = 0xff;
+dest[3] = 0xff;
} else {
-dest[0] = 0x50;
-dest[1] = 0x50;
-dest[2] = 0x50;
-dest[3] = 0x30;
+dest[0] = 0x00;
+dest[1] = 0x00;
+dest[2] = 0x00;
+dest[3] = 0x00;
}
} else {
/* unchanged - transparent */
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] wireshark codegen
Opinions on this? The end goal is to be able to generate a header that has
both the enums and descriptions of those enum values (e.g. a mapping from
enum to string name) that we can use for the wireshark dissector.
Obviously, when a new channel or new message gets added to the protocol,
there is still some manual work that needs to be done to update the
wireshark dissector, but being able to autogenerate theses values reduces
the maintenance burden for this part at least.
Hi Jonathon,
I'm not sure what opinions you are looking for. The only one I have is go
ahead! great work!
Alon
From c6cef8747b61e203ebb8ade580dae063d581afb2 Mon Sep 17 00:00:00 2001
From: Jonathon Jongsma jjong...@redhat.com
Date: Thu, 12 Sep 2013 12:11:02 -0500
Subject: [PATCH] codegen: Add a --generate-wireshark-dissector option
The wireshark protocol dissector is a bit out-of-date. Several new channel
types
and enums have been added. It would be nice if these values (and the
translation between the value and the name) could be automatically generated
so
that updating the dissector was a slightly less manual process. This patch
adds
a commandline switch which generates both the enums and value-name lists in
the
format that wireshark expects.
---
python_modules/codegen.py | 2 +-
python_modules/ptypes.py | 17
spice_codegen.py | 105
++
3 files changed, 87 insertions(+), 37 deletions(-)
diff --git a/python_modules/codegen.py b/python_modules/codegen.py
index 009cf95..5dee0b8 100644
--- a/python_modules/codegen.py
+++ b/python_modules/codegen.py
@@ -41,7 +41,7 @@ def set_prefix(prefix):
def prefix_underscore_upper(*args):
s = proto_prefix_upper
for arg in args:
-s = s + _ + arg
+s = s + _ + arg.upper()
return s
def prefix_underscore_lower(*args):
diff --git a/python_modules/ptypes.py b/python_modules/ptypes.py
index d9fbfe2..2bfbf0d 100644
--- a/python_modules/ptypes.py
+++ b/python_modules/ptypes.py
@@ -247,6 +247,23 @@ class EnumBaseType(Type):
def get_fixed_nw_size(self):
return self.bits / 8
+# generates a value-name table suitable for use with the wireshark
protocol
+# dissector
+def c_describe(self, writer):
+writer.write(static const value_string %s_vs[] = %
codegen.prefix_underscore_lower(self.name))
+writer.begin_block()
+values = self.names.keys()
+values.sort()
+for i in values:
+writer.write({ )
+writer.write(self.c_enumname(i))
+writer.write(, \%s\ }, % self.names[i])
+writer.newline()
+writer.write({ 0, NULL })
+writer.end_block(semicolon=True)
+writer.newline()
+
+
class EnumType(EnumBaseType):
def __init__(self, bits, name, enums, attribute_list):
Type.__init__(self)
diff --git a/spice_codegen.py b/spice_codegen.py
index e9e64c0..de1f87b 100755
--- a/spice_codegen.py
+++ b/spice_codegen.py
@@ -10,38 +10,73 @@ from python_modules import codegen
from python_modules import demarshal
from python_modules import marshal
-def write_channel_enums(writer, channel, client):
+def write_channel_enums(writer, channel, client, describe):
messages = filter(lambda m : m.channel == channel, \
channel.client_messages if client else
channel.server_messages)
if len(messages) == 0:
return
-writer.begin_block(enum)
-i = 0
if client:
-prefix = [ MSGC ]
+prefix = [ msgc ]
else:
-prefix = [ MSG ]
+prefix = [ msg ]
if channel.member_name:
-prefix.append(channel.member_name.upper())
+prefix.append(channel.member_name)
+if not describe:
+writer.begin_block(enum)
+else:
+writer.begin_block(static const value_string %s_vs[] = %
(codegen.prefix_underscore_lower(*prefix)))
+i = 0
prefix.append(None) # To be replaced with name
for m in messages:
-prefix[-1] = m.name.upper()
+prefix[-1] = m.name
enum = codegen.prefix_underscore_upper(*prefix)
-if m.value == i:
-writer.writeln(%s, % enum)
-i = i + 1
+if describe:
+writer.writeln({ %s, \%s %s\ }, % (enum, Client if client
else Server, m.name.upper()))
else:
-writer.writeln(%s = %s, % (enum, m.value))
-i = m.value + 1
-if channel.member_name:
-prefix[-1] = prefix[-2]
-prefix[-2] = END
-writer.newline()
-writer.writeln(%s % (codegen.prefix_underscore_upper(*prefix)))
+if m.value == i:
+writer.writeln(%s, % enum)
+i = i + 1
+else:
+writer.writeln(%s = %s, % (enum, m.value))
+i = m.value + 1
+if
Re: [Spice-devel] [spice-html5] Send the client cache size correctly in little endian order so we don't claim to have an infinitely large cache.
Signed-off-by: Jeremy White jwh...@codeweavers.com
Looks good to me, Ack.
---
spicedataview.js | 12
spicemsg.js |3 +--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/spicedataview.js b/spicedataview.js
index ef9555d..43f0170 100644
--- a/spicedataview.js
+++ b/spicedataview.js
@@ -93,4 +93,16 @@ SpiceDataView.prototype = {
this.setUint16(byteOffset + high, (w 0x) 16,
littleEndian);
this.setUint16(byteOffset + low, (w 0x), littleEndian);
},
+setUint64: function(byteOffset, w, littleEndian)
+{
+var low = 4, high = 0;
+if (littleEndian)
+{
+low = 0;
+high = 4;
+}
+
+this.setUint32(byteOffset + high, (w 0x) 32,
littleEndian);
+this.setUint32(byteOffset + low, (w 0x),
littleEndian);
+},
}
diff --git a/spicemsg.js b/spicemsg.js
index 365fdf7..e342d6a 100644
--- a/spicemsg.js
+++ b/spicemsg.js
@@ -445,8 +445,7 @@ SpiceMsgcDisplayInit.prototype =
at = at || 0;
var dv = new SpiceDataView(a);
dv.setUint8(at, this.pixmap_cache_id, true); at++;
-dv.setUint32(at, 0, true); at += 4;
-dv.setUint32(at, this.pixmap_cache_size, true); at += 4;
+dv.setUint64(at, this.pixmap_cache_size, true); at += 8;
dv.setUint8(at, this.glz_dictionary_id, true); at++;
dv.setUint32(at, this.glz_dictionary_window_size, true); at += 4;
},
--
1.7.10.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [spice-html5] Give the Garbage collector a clue to recycle images; avoids fairly massive memory leaks during video playback.
ACK.
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
display.js |4
1 file changed, 4 insertions(+)
diff --git a/display.js b/display.js
index f9bfe76..d0d0994 100644
--- a/display.js
+++ b/display.js
@@ -778,6 +778,10 @@ function handle_draw_jpeg_onload()
{
context.drawImage(this, this.o.base.box.left, this.o.base.box.top);
+// Give the Garbage collector a clue to recycle this; avoids
+// fairly massive memory leaks during video playback
+this.src = null;
+
if (this.o.descriptor
(this.o.descriptor.flags SPICE_IMAGE_FLAGS_CACHE_ME))
{
--
1.7.10.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [winswitch] [Spice-devel] Use spice to show individual X clients like xpra does?
On 10/09/13 01:16, Alon Levy wrote: Hi - Original Message - Hi, I've played around a bit with xpra[1]. Xpra (AFAIK) starts an X server with a dummy video driver (or xvfb?) on the remote machine and a client xpra process on the local machine shows remote application windows just like they would run locally. [1] http://xpra.org Xpra also forwards sound, clipboard and microfon. So it seems to me that there is some overlap with spice. It would be cool, if I could use spice in the same way, to see virtual machine X clients integrated in my local desktop just like local applications. Is this on your roadmap? It would be really nice to have, but nobody is working on this afaik. The current spice project is more designed toward driver level, rather than application level. You'd need to have a per-window drawing context in order to be able to display the seamless apps correctly. On Windows, it would probably need user-space gdi (directx) hooks (somehow a bit like wine). Older methods just clip the remote windows with help of the window manager, however this is quite limited (see seamlessrdp or virtualbox seamless mode etc). I haven't looked at xpra, it would be interesting to see if and how they manage this per-window context. Perhaps it is possible to extend Xspice similarly? but I suppose it is rather done at higher level (application or X server frontend). See http://xpra.org/trac/browser/xpra/trunk/src/README I have to confess I used it some time in the past and completely forgot about it, thanks for bringing it up! It is of course X specific, Mostly yes, though the codebase no longer has any hard X11 dependencies for servers: the shadow mode works with MS Windows servers too for example (though at present it is no more than a cheap x0vncserver equivalent - just screen scraping). (and there are clients in python and Java for many platforms) it uses Xvfb and becomes a compositing manager on top of it, and instead of compositing forwards the images to the remote X server, and also acts as a window manager deferring all app requests to the remote window manager on the client X. I haven't looked at the protocol, The wire protocol is pretty simple, and supports bencoded data (or rencoded data which is much faster) with a very limited set of commands for mapping/moving windows, etc. I guess another feature that would be relevant to you would be notification forwarding, the rest is probably handled already. or copy paste support, Is fully supported on all client platforms, but is one way only for OSX clients at present. or audio, We use gstreamer to compress the audio, usually as mp3 via lame. which at this point Xspice supports. It should be easy to use the compositing manager + window manager bits (not sure about language). Easy is not the word I would have chosen here ;) But maybe spice makes it easier somehow? You got me, I was using easy as in easy to show but there isn't enough room in this email to include the proof. I mostly assumed I could take it as is, and would be left with introducing the protocol bits. Antoine And teach the client of course to implement them too. Any takers? ___ Spice-devel mailing list spice-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ shifter-users mailing list shifter-users@lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users ___ Spice-devel mailing list spice-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ shifter-users mailing list shifter-users@lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users
Re: [Spice-devel] [winswitch] Use spice to show individual X clients like xpra does?
On 10/09/13 01:16, Alon Levy wrote: Hi - Original Message - Hi, I've played around a bit with xpra[1]. Xpra (AFAIK) starts an X server with a dummy video driver (or xvfb?) on the remote machine and a client xpra process on the local machine shows remote application windows just like they would run locally. [1] http://xpra.org Xpra also forwards sound, clipboard and microfon. So it seems to me that there is some overlap with spice. It would be cool, if I could use spice in the same way, to see virtual machine X clients integrated in my local desktop just like local applications. Is this on your roadmap? It would be really nice to have, but nobody is working on this afaik. The current spice project is more designed toward driver level, rather than application level. You'd need to have a per-window drawing context in order to be able to display the seamless apps correctly. On Windows, it would probably need user-space gdi (directx) hooks (somehow a bit like wine). Older methods just clip the remote windows with help of the window manager, however this is quite limited (see seamlessrdp or virtualbox seamless mode etc). I haven't looked at xpra, it would be interesting to see if and how they manage this per-window context. Perhaps it is possible to extend Xspice similarly? but I suppose it is rather done at higher level (application or X server frontend). See http://xpra.org/trac/browser/xpra/trunk/src/README I have to confess I used it some time in the past and completely forgot about it, thanks for bringing it up! It is of course X specific, Mostly yes, though the codebase no longer has any hard X11 dependencies for servers: the shadow mode works with MS Windows servers too for example (though at present it is no more than a cheap x0vncserver equivalent - just screen scraping). (and there are clients in python and Java for many platforms) it uses Xvfb and becomes a compositing manager on top of it, and instead of compositing forwards the images to the remote X server, and also acts as a window manager deferring all app requests to the remote window manager on the client X. I haven't looked at the protocol, The wire protocol is pretty simple, and supports bencoded data (or rencoded data which is much faster) with a very limited set of commands for mapping/moving windows, etc. I guess another feature that would be relevant to you would be notification forwarding, the rest is probably handled already. or copy paste support, Is fully supported on all client platforms, but is one way only for OSX clients at present. or audio, We use gstreamer to compress the audio, usually as mp3 via lame. which at this point Xspice supports. It should be easy to use the compositing manager + window manager bits (not sure about language). Easy is not the word I would have chosen here ;) But maybe spice makes it easier somehow? You got me, I was using easy as in easy to show but there isn't enough room in this email to include the proof. I mostly assumed I could take it as is, and would be left with introducing the protocol bits. Antoine And teach the client of course to implement them too. Any takers? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ shifter-users mailing list shifter-us...@lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] unsupported partial overlap
Hi, it has been reported (https://bugs.launchpad.net/ubuntu/+source/spice/+bug/1212704) that in a multi-monitor setup with partial overlap, spicy runs fine but spicec refused to run. This is explicitly checked for in client/x11/platform.cpp:crtc_overlap_test(). I've looked at the git tree for the origins, but it's been there since the first commit (fresh start). Is this something that's really needed i.e. due to the way spicec does rendering? I am not sure. Have you tried removing crtc_overlap_test and testing? Note that this is low priority for us, since we prefer everyone switch to the supported viewer, remote-viewer, based off spice-gtk. thanks, -serge ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] unsupported partial overlap
Quoting Alon Levy (al...@redhat.com): Hi, it has been reported (https://bugs.launchpad.net/ubuntu/+source/spice/+bug/1212704) that in a multi-monitor setup with partial overlap, spicy runs fine but spicec refused to run. This is explicitly checked for in client/x11/platform.cpp:crtc_overlap_test(). I've looked at the git tree for the origins, but it's been there since the first commit (fresh start). Is this something that's really needed i.e. due to the way spicec does rendering? I am not sure. Have you tried removing crtc_overlap_test and testing? Yup, that works perfectly. (just removing the 3 lines which test and throw the exception). Want to send a patch? I'm a bit hesitant because I still don't know the original reason, perhaps this is not supported somehow by older X servers? maybe you will get more comments with a patch ;) Note that this is low priority for us, since we prefer everyone switch to the supported viewer, remote-viewer, based off spice-gtk. Thanks, that is also good to know. Perhaps we should add a deprecation message to spicec. That would work for whomever is building spicec from source only. Still it's a good idea. -serge ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [winswitch] [Spice-devel] Use spice to show individual X clients like xpra does?
Hi - Original Message - Hi, I've played around a bit with xpra[1]. Xpra (AFAIK) starts an X server with a dummy video driver (or xvfb?) on the remote machine and a client xpra process on the local machine shows remote application windows just like they would run locally. [1] http://xpra.org Xpra also forwards sound, clipboard and microfon. So it seems to me that there is some overlap with spice. It would be cool, if I could use spice in the same way, to see virtual machine X clients integrated in my local desktop just like local applications. Is this on your roadmap? It would be really nice to have, but nobody is working on this afaik. The current spice project is more designed toward driver level, rather than application level. You'd need to have a per-window drawing context in order to be able to display the seamless apps correctly. On Windows, it would probably need user-space gdi (directx) hooks (somehow a bit like wine). Older methods just clip the remote windows with help of the window manager, however this is quite limited (see seamlessrdp or virtualbox seamless mode etc). I haven't looked at xpra, it would be interesting to see if and how they manage this per-window context. Perhaps it is possible to extend Xspice similarly? but I suppose it is rather done at higher level (application or X server frontend). See http://xpra.org/trac/browser/xpra/trunk/src/README I have to confess I used it some time in the past and completely forgot about it, thanks for bringing it up! It is of course X specific, it uses Xvfb and becomes a compositing manager on top of it, and instead of compositing forwards the images to the remote X server, and also acts as a window manager deferring all app requests to the remote window manager on the client X. I haven't looked at the protocol, or copy paste support, or audio, which at this point Xspice supports. It should be easy to use the compositing manager + window manager bits (not sure about language). And teach the client of course to implement them too. Any takers? ___ Spice-devel mailing list spice-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ shifter-users mailing list shifter-users@lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users
Re: [Spice-devel] Use spice to show individual X clients like xpra does?
Hi - Original Message - Hi, I've played around a bit with xpra[1]. Xpra (AFAIK) starts an X server with a dummy video driver (or xvfb?) on the remote machine and a client xpra process on the local machine shows remote application windows just like they would run locally. [1] http://xpra.org Xpra also forwards sound, clipboard and microfon. So it seems to me that there is some overlap with spice. It would be cool, if I could use spice in the same way, to see virtual machine X clients integrated in my local desktop just like local applications. Is this on your roadmap? It would be really nice to have, but nobody is working on this afaik. The current spice project is more designed toward driver level, rather than application level. You'd need to have a per-window drawing context in order to be able to display the seamless apps correctly. On Windows, it would probably need user-space gdi (directx) hooks (somehow a bit like wine). Older methods just clip the remote windows with help of the window manager, however this is quite limited (see seamlessrdp or virtualbox seamless mode etc). I haven't looked at xpra, it would be interesting to see if and how they manage this per-window context. Perhaps it is possible to extend Xspice similarly? but I suppose it is rather done at higher level (application or X server frontend). See http://xpra.org/trac/browser/xpra/trunk/src/README I have to confess I used it some time in the past and completely forgot about it, thanks for bringing it up! It is of course X specific, it uses Xvfb and becomes a compositing manager on top of it, and instead of compositing forwards the images to the remote X server, and also acts as a window manager deferring all app requests to the remote window manager on the client X. I haven't looked at the protocol, or copy paste support, or audio, which at this point Xspice supports. It should be easy to use the compositing manager + window manager bits (not sure about language). And teach the client of course to implement them too. Any takers? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH qxl-win] Revert miniport: halve QXL_IO_UPDATE_IRQ calls
This reverts commit 49feefa95d3595f04355c4aed53ec5bf26551046.
The patch causes the display to get stuck. Till we understand exactly
why, I'm reverting it.
ACK.
---
xddm/miniport/qxl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xddm/miniport/qxl.c b/xddm/miniport/qxl.c
index ce37f07..f5d6b48 100644
--- a/xddm/miniport/qxl.c
+++ b/xddm/miniport/qxl.c
@@ -1321,6 +1321,7 @@ BOOLEAN Interrupt(PVOID dev_extension)
return FALSE;
}
dev_ext-ram_header-int_mask = 0;
+VideoPortWritePortUchar((PUCHAR)dev_ext-io_base + QXL_IO_UPDATE_IRQ,
0);
if (!VideoPortQueueDpc(dev_extension, InterruptCallback, NULL)) {
VideoPortLogError(dev_extension, NULL, E_UNEXPECTED,
QXLERR_INT_DELIVERY);
--
1.8.1.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
