Re: [Spice-devel] [PATCH] usbredirparser: prevent endless recursion if interface_count == 0
Thanks!
On Wed, Aug 3, 2016, at 01:49 PM, Christophe Fergeau wrote:
> Hey,
>
> I've pushed the patch now, thanks!
>
> Christophe
>
> On Tue, Jul 26, 2016 at 01:47:16PM +0300, Alon Levy wrote:
> > On fedora 24 this function is tail optimized, resulting in a busy wait.
> >
> > This happens to me with virt-manager running a win7 vm
> >
> > usbredir-0.7.1-2.fc24.x86_64
> > ---
> > Hi Guys!
> >
> > One liner to fix an issue I had with virt-manager - symptom is 100% cpu
> > taken in it, stack traced to the problem fixed by this patch.
> >
> > Alon
> >
> > usbredirparser/usbredirfilter.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/usbredirparser/usbredirfilter.c
> > b/usbredirparser/usbredirfilter.c
> > index 02184ef..bdfbfc2 100644
> > --- a/usbredirparser/usbredirfilter.c
> > +++ b/usbredirparser/usbredirfilter.c
> > @@ -205,7 +205,7 @@ int usbredirfilter_check(
> > * by recursively calling this function with a flag that forbids
> > * skipping (usbredirfilter_fl_dont_skip_non_boot_hid)
> > */
> > -if (num_skipped == interface_count) {
> > +if (interface_count > 0 && num_skipped == interface_count) {
> > rc = usbredirfilter_check(rules, rules_count,
> >device_class, device_subclass,
> >device_protocol,
> >interface_class, interface_subclass,
> > --
> > 2.7.4
> > ___
> > Spice-devel mailing list
> > Spice-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/spice-devel
> Email had 1 attachment:
> + signature.asc
> 1k (application/pgp-signature)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] usbredirparser: prevent endless recursion if interface_count == 0
On fedora 24 this function is tail optimized, resulting in a busy wait.
This happens to me with virt-manager running a win7 vm
usbredir-0.7.1-2.fc24.x86_64
---
Hi Guys!
One liner to fix an issue I had with virt-manager - symptom is 100% cpu
taken in it, stack traced to the problem fixed by this patch.
Alon
usbredirparser/usbredirfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/usbredirparser/usbredirfilter.c
b/usbredirparser/usbredirfilter.c
index 02184ef..bdfbfc2 100644
--- a/usbredirparser/usbredirfilter.c
+++ b/usbredirparser/usbredirfilter.c
@@ -205,7 +205,7 @@ int usbredirfilter_check(
* by recursively calling this function with a flag that forbids
* skipping (usbredirfilter_fl_dont_skip_non_boot_hid)
*/
-if (num_skipped == interface_count) {
+if (interface_count > 0 && num_skipped == interface_count) {
rc = usbredirfilter_check(rules, rules_count,
device_class, device_subclass,
device_protocol,
interface_class, interface_subclass,
--
2.7.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Virtual Smartcard GPG
On 04/29/2015 09:22 PM, r...@openmailbox.org wrote: On 2015-04-29 11:41, Alon Levy wrote: On 04/29/2015 02:20 PM, r...@openmailbox.org wrote: Hi. I am trying to get a virtual smartcard attached to a vm but I want it to use GPG instead of NSS. RedHat focuses on NSS becuase of PKCS#11 requirements and FIPS approval, but for most of the community its GPG that matters for smartcards. Is is possible to use GPG on the host instead of NSS with virtual smartcards? Please document how or add support for it. Is using a virtual smartcard make the host less secure from a rogue vm? If there are bugs in GPG/NSS backend on the host can they be abused by untrusted code in the vm? There are two implementations, one is passthrough and another uses a virtual card on the client side, both end up using the client NSS APIs for access to the hardware card, assuming in your case host=client then there is no more or less propensity for abuse then launching any local program (with the same credentials as the spice viewer). Does the mode with the virtual card on the client side still require use of a physical smartcard? I thought it read encryption secrets stored on the host but presented them to the guest securely in the manner of a virtual smartcard device. The host certificates mode implies it. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sub-section-libvirt-dom-xml-devices-smartcard.html This mode allows you to provide three NSS certificate names residing in a database on the host physical machine, rather than requiring a smartcard to be plugged into the host physical machine. These certificates can be generated via the command certutil -d /etc/pki/nssdb -x -t CT,CT,CT -S -s CN=cert1 -n cert1, and the resulting three certificate names must be supplied as the content of each of three certificate sub-elements. Right, you can also use the virtual card emulation without hardware like the docs you quoted say. It also gave me the idea that changing the path from /etc/pki/nssdb to gpg's pubkeyring is probable? I don't know anything about that. ___ 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] Virtual Smartcard GPG
On 04/29/2015 02:20 PM, r...@openmailbox.org wrote: Hi. I am trying to get a virtual smartcard attached to a vm but I want it to use GPG instead of NSS. RedHat focuses on NSS becuase of PKCS#11 requirements and FIPS approval, but for most of the community its GPG that matters for smartcards. Is is possible to use GPG on the host instead of NSS with virtual smartcards? Please document how or add support for it. Is using a virtual smartcard make the host less secure from a rogue vm? If there are bugs in GPG/NSS backend on the host can they be abused by untrusted code in the vm? There are two implementations, one is passthrough and another uses a virtual card on the client side, both end up using the client NSS APIs for access to the hardware card, assuming in your case host=client then there is no more or less propensity for abuse then launching any local program (with the same credentials as the spice viewer). ___ 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] [xf86-video-qxl v6] Enable smartcard support for XSpice.
On 01/08/2015 04:10 PM, Jeremy White wrote:
On 01/08/2015 03:53 AM, Uri Lublin wrote:
Hi Jeremy,
Ack.
Thanks.
h-length is unsigned.
1. Why is there a need to check that h-length 0 ?
There is no need, changed.
2. What happens if h-length == 0 ?
Note that I believe that could only occur in the case of a malicious or
buggy packet. By inspection, I believe the code will all function
correctly; passing a 0 length atr along.
Is this to the card (hardware) or back? if to, can't this be used by a
driver to wakeup a card (i.e. dropping it will have adverse affects)?
+static void process_apdu(smartcard_ccid_t *ccid, VSCMsgHeader *h,
char *data)
+{
+if (ccid-state STATE_READER_ADDED)
+push_apdu(ccid, data, h-length);
Maybe add: else { fprintf(stderr, warning ... }
Sure.
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] [PATCH spice-protocol] build-sys: simplify autogen
[snip] At the same time, I'm not sure mailing lists are the right tool for code review. It's difficult to track which patches have been reviewed and which haven't. http://patchwork.freedesktop.org/project/Spice/list/ can help, linked from the wiki btw (http://www.spice-space.org/page/Main_Page) (not getting into this otherwise :) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-protocol] build-sys: simplify autogen
On 12/06/2014 12:00 AM, Jonathon Jongsma wrote: On Fri, 2014-12-05 at 23:41 +0200, Alon Levy wrote: [snip] At the same time, I'm not sure mailing lists are the right tool for code review. It's difficult to track which patches have been reviewed and which haven't. http://patchwork.freedesktop.org/project/Spice/list/ can help, linked from the wiki btw (http://www.spice-space.org/page/Main_Page) (not getting into this otherwise :) Thanks, I had forgotten about that. I notice now that all patches listed on that site are in state New. Is there a magical incantation we can insert into our review that will change the patch state to Approved or Needs Work or something? If so, can we start using this incantation rather than our traditional ACK, so that patchwork will be able to track the true state of these patches? I don't know that magic, but it does sound handy. Jonathon ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Spice agent and LXC
On 11/27/2014 02:02 PM, Charles Ricketts wrote: Well, I have Spice working perfectly fine in a Windows install. However, seeing as that's not pertinent to the Linux side of things I went ahead and installed Ubuntu 14.04 in Qemu and, as expected, everything worked. I didn't bother with the git sources in this install, because I was 99% sure it was going to work anyway. I don't have a Fedora ISO lying around to test it with, but I imagine that the results would be the same. However, I don't think that even this is pertinent to the problem. The reason I think this is because Qemu acts as the Spice server if I am correct. Qemu relays information from a network socket assigned on the command line to the virtualized serial port and vice versa. Since an LXC installation is sans-Qemu server then I must use Xspice in order to take the place of Qemu and act as a Spice server in order to relay information between the agents/QXL driver and the Spice client. So, testing it within Qemu doesn't really reflect the problem at all. Beyond Qemu, there's really no way to test it sans-LXC. Actually, now that I think about it I may be able to run Xspice directly within a VM and then attempt to connect to it... I'll try that out later on and let you know how/if that works out. I may have to get that Fedora ISO after all just to broaden the test cases. I realize that I'm effectively attempting to use Spice outside of normal circumstances. However, the way that Xspice behaves -- such as creating its own versions of the virtio port (as a socket rather than a character device) and uinput (as a pipe) and attempting to destroy any existing versions of those files -- leads me to believe that Xspice was almost built for the purpose even if not intentionally. And, as I had said before, I got it mostly working in a Fedora LXC container (only lacking client functionality, which is why I asked for input in the first place ;). Xspice can definitely be used in a container, since it can also be used without one. Did you manage to run it as is, i.e. Xspice command line arguments plus connecting with both spice client (remote-viewer) and X clients (window manager etc.) ? If not, and it crashed doing that, getting a meaningful stack trace would require building Xspice with debug symbols - something that should be available on ubuntu without the need to build from source. Are you using ubuntu? [snip] ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [xf86-video-qxl] Enable smartcard support for XSpice.
On 11/21/2014 05:03 PM, Jeremy White wrote:
Thanks for the careful review.
+static void push_apdu(smartcard_ccid_t *ccid, void *data, int len)
+{
+apdu_t *a = calloc(1, sizeof(*a) + len);
+apdu_t **p;
+
+a-data = malloc(len);
+memcpy(a-data, data, len);
1. No need to add ( + len ) to the calloc above
as a-data is malloced.
Is that space is used somewhere else ?
No, you're right; that's a leftover from a different approach.
2. missing a-len = len
*blush* Deleted some debugging before sending...deleted one line too many.
3. Nitpick: I think it's more readable to explicitly add a-next = NULL
even though it is 0 from the calloc (maybe use malloc
as all fields are set). Not that important.
I don't feel strongly; I'll change it as a form of thanks grin.
+static void * lun_thread(void *arg)
+{
+char buf[8096];
+static int pos = 0;
Why have pos static (especially when buf is not) ?
Artifact of an earlier implementation; good catch.
+for (i = 0; i MAX_LUNS; i++)
+if (luns[i].fd != -1 luns[i].lun == Lun) {
+while (p = pop_apdu(luns[i]))
+free_apdu(p);
Are those left-overs from previous commands ?
Are those apdu not important enough to be processed ?
Reading below I see that some (all?) of those are late apdu's
coming in after the timeout.
I think you mostly answered this one.
To be fair, this code is solving a theoretical problem, not one I
encountered in testing. I think the reasonable, if unlikely, case is an
instance where an application requests data from a smart card, but then
either aborts or times out, without clearing the response from the
pipeline.
+
+if (send_tx_buffer(luns[i], TxBuffer, TxLength)) {
+for (j = 0; j TX_MAX_SLEEP; j++)
+if (p = pop_apdu(luns[i]))
+break;
+else
+usleep(TX_SLEEP_INTERVAL);
+
+if (p) {
+memcpy(RxBuffer, p-data, MIN(p-len, *RxLength));
+*RxLength = MIN(p-len, *RxLength);
+free_apdu(p);
+return IFD_SUCCESS;
+}
maybe better here: else return IFD_RESPONSE_TIMEOUT
Yes.
+}
+}
+return IFD_ERROR_NOT_SUPPORTED;
and here IFD_ICC_NOT_PRESENT (?)
I think actually IFD_NO_SUCH_DEVICE would be more correct.
+unlink(qxl-smartcard_file);
Another nitpick:
I see the vdagent unix-domain-socket file is not
unlinked in the code. It is done in scripts/Xspice.
Hmm. I'm not sure why Alon chose to do it that way.
But the unlink feels right to me; I can't think of a benefit of removing
it. And removing it would create a perpetual chore for any caller
(whether script or otherwise).
I agree with both of you for what it's worth.
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] [PATCH][spice-gtk] Add GStreamer 1.0 support
On 10/30/2014 06:39 PM, vtoso...@redhat.com wrote:
From: Christophe Fergeau cferg...@redhat.com
This commit adds GStreamer 1.0 support.
To enable GStreamer 1.0: --with-audio=gstreamer1
commit first line should say audio somewhere.
There is only a few changes between those versions, worth mentioning:
- audio capabilities audio/x-raw,format=... instead of
audio/x-raw-int,...
- appsink signal for new data changed from new-buffer to new-sample
---
configure.ac | 17 +++---
gtk/spice-audio.c| 4 ++--
gtk/spice-gstaudio.c | 64
+++-
3 files changed, 79 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0d65823..17680e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -288,7 +288,7 @@ AS_IF([test x$have_phodav = xyes],
AC_DEFINE(USE_PHODAV, [1], [Define if supporting phodav]))
AC_ARG_WITH([audio],
- AS_HELP_STRING([--with-audio=@:@gstreamer/pulse/auto/no@:@], [Select
audio backend @:@default=auto@:@]),
+ AS_HELP_STRING([--with-audio=@:@gstreamer/gstreamer1/pulse/auto/no@:@],
[Select audio backend @:@default=auto@:@]),
[],
[with_audio=auto])
@@ -297,7 +297,7 @@ AS_IF([test x$with_audio = xauto], [
])
case $with_audio in
- gstreamer|pulse|no*)
+ gstreamer|gstreamer1|pulse|no*)
;;
*) AC_MSG_ERROR(Unsupported audio backend)
esac
@@ -326,7 +326,18 @@ AS_IF([test x$have_gst = xyes],
[AC_MSG_ERROR([GStreamer requested but not found])
])
])
-AM_CONDITIONAL([WITH_GSTAUDIO], [test x$have_gst = xyes])
+
+AS_IF([test x$with_audio = xgstreamer1],
+ [PKG_CHECK_MODULES(GST, gstreamer-1.0 gstreamer-base-1.0
gstreamer-app-1.0 gstreamer-audio-1.0, [have_gst1=yes], [have_gst1=no])],
+ [have_gst1=no])
+
+AS_IF([test x$have_gst1 = xyes],
+ [AC_DEFINE([WITH_GST1AUDIO], 1, [Have GStreamer 1.0?])],
+ [AS_IF([test x$with_audio = xgstreamer1],
+ [AC_MSG_ERROR([GStreamer 1.0 requested but not found])
+ ])
+])
+AM_CONDITIONAL([WITH_GSTAUDIO], [test x$have_gst = xyes -o x$have_gst1
= xyes])
AC_SUBST(GST_CFLAGS)
AC_SUBST(GST_LIBS)
diff --git a/gtk/spice-audio.c b/gtk/spice-audio.c
index dbd3a8b..34c1b69 100644
--- a/gtk/spice-audio.c
+++ b/gtk/spice-audio.c
@@ -47,7 +47,7 @@
#ifdef WITH_PULSE
#include spice-pulse.h
#endif
-#ifdef WITH_GSTAUDIO
+#if defined(WITH_GSTAUDIO) || defined(WITH_GST1AUDIO)
#include spice-gstaudio.h
#endif
@@ -219,7 +219,7 @@ SpiceAudio *spice_audio_new(SpiceSession *session,
GMainContext *context,
#ifdef WITH_PULSE
self = SPICE_AUDIO(spice_pulse_new(session, context, name));
#endif
-#ifdef WITH_GSTAUDIO
+#if defined(WITH_GSTAUDIO) || defined(WITH_GST1AUDIO)
self = SPICE_AUDIO(spice_gstaudio_new(session, context, name));
#endif
if (!self)
diff --git a/gtk/spice-gstaudio.c b/gtk/spice-gstaudio.c
index faa0c74..d3c091a 100644
--- a/gtk/spice-gstaudio.c
+++ b/gtk/spice-gstaudio.c
@@ -21,9 +21,13 @@
#include gst/gst.h
#include gst/app/gstappsrc.h
-#include gst/app/gstappbuffer.h
#include gst/app/gstappsink.h
+#ifdef WITH_GST1AUDIO
+#include gst/audio/streamvolume.h
+#else
+#include gst/app/gstappbuffer.h
#include gst/interfaces/streamvolume.h
+#endif
#include spice-gstaudio.h
#include spice-common.h
@@ -133,7 +137,12 @@ static void record_new_buffer(GstAppSink *appsink,
gpointer data)
g_return_if_fail(p != NULL);
+#ifdef WITH_GST1AUDIO
+msg = gst_message_new_application(GST_OBJECT(p-record.pipe),
+ gst_structure_new_empty
(new-sample));
+#else
msg = gst_message_new_application(GST_OBJECT(p-record.pipe), NULL);
+#endif
gst_element_post_message(p-record.pipe, msg);
}
@@ -155,6 +164,38 @@ static gboolean record_bus_cb(GstBus *bus, GstMessage
*msg, gpointer data)
g_return_val_if_fail(p != NULL, FALSE);
switch (GST_MESSAGE_TYPE(msg)) {
+#ifdef WITH_GST1AUDIO
+case GST_MESSAGE_APPLICATION: {
+GstSample *s;
+GstBuffer *buffer;
+GstMapInfo mapping;
+
+s = gst_app_sink_pull_sample(GST_APP_SINK(p-record.sink));
+if (!s) {
+if (!gst_app_sink_is_eos(GST_APP_SINK(p-record.sink)))
+g_warning(eos not reached, but can't pull new sample);
+return TRUE;
+}
+
+buffer = gst_sample_get_buffer(s);
+if (!buffer) {
+if (!gst_app_sink_is_eos(GST_APP_SINK(p-record.sink)))
+g_warning(eos not reached, but can't pull new buffer);
+return TRUE;
+}
+if (!gst_buffer_map(buffer, mapping, GST_MAP_READ)) {
+return TRUE;
+}
+
+spice_record_send_data(SPICE_RECORD_CHANNEL(p-rchannel),
+ /* FIXME: server side doesn't care about ts?
+ what is the
Re: [Spice-devel] [vdagent-linux v2] randr: handle XRRScreenChangeNotifyEvent
On 10/08/2014 01:10 PM, Marc-André Lureau wrote:
ping
I didn't test this, looks good, just one single line if, do with it as
you will. And unrelated, but you use TRUE/FALSE constants for handled,
maybe nice to use them too (at least be consistent that is) in
vdagent_x11_handle_event.
On Mon, Sep 8, 2014 at 11:34 AM, Marc-André Lureau
marcandre.lur...@gmail.com mailto:marcandre.lur...@gmail.com wrote:
ping
On Wed, Aug 27, 2014 at 8:51 PM, Marc-André Lureau
marcandre.lur...@redhat.com mailto:marcandre.lur...@redhat.com
wrote:
From: Marc-Andre Lureau marcandre.lur...@redhat.com
mailto:marcandre.lur...@redhat.com
Make sure vdagent follows the current monitor configuration. This
solves a number of issue where the pointer input is off, because the
uinput tablet isn't reconfigured.
https://bugzilla.redhat.com/show_bug.cgi?id=1086657
---
src/vdagent-x11-priv.h | 4 +++-
src/vdagent-x11-randr.c | 34 +-
src/vdagent-x11.c | 4 +++-
3 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/src/vdagent-x11-priv.h b/src/vdagent-x11-priv.h
index 38f852e..d60cc07 100644
--- a/src/vdagent-x11-priv.h
+++ b/src/vdagent-x11-priv.h
@@ -95,6 +95,7 @@ struct vdagent_x11 {
int height[MAX_SCREENS];
int has_xfixes;
int xfixes_event_base;
+int xrandr_event_base;
int max_prop_size;
int expected_targets_notifies[256];
int clipboard_owner[256];
@@ -145,7 +146,8 @@ void
vdagent_x11_send_daemon_guest_xorg_res(struct vdagent_x11 *x11,
int update);
void vdagent_x11_randr_handle_root_size_change(struct
vdagent_x11 *x11,
int screen, int
width, int height);
-
+int vdagent_x11_randr_handle_event(struct vdagent_x11 *x11,
+XEvent event);
void vdagent_x11_set_error_handler(struct vdagent_x11 *x11,
int (*handler)(Display *, XErrorEvent *));
int vdagent_x11_restore_error_handler(struct vdagent_x11 *x11);
diff --git a/src/vdagent-x11-randr.c b/src/vdagent-x11-randr.c
index 5faaee6..c6f790e 100644
--- a/src/vdagent-x11-randr.c
+++ b/src/vdagent-x11-randr.c
@@ -132,12 +132,15 @@ void vdagent_x11_randr_init(struct
vdagent_x11 *x11)
return;
}
-if (XRRQueryExtension(x11-display, i, i)) {
+if (XRRQueryExtension(x11-display,
x11-xrandr_event_base, i)) {
XRRQueryVersion(x11-display, x11-xrandr_major,
x11-xrandr_minor);
if (x11-xrandr_major == 1 x11-xrandr_minor = 3)
x11-has_xrandr = 1;
}
+XRRSelectInput(x11-display, x11-root_window[0],
+RRScreenChangeNotifyMask | RRCrtcChangeNotifyMask);
+
if (x11-has_xrandr) {
update_randr_res(x11, 0);
} else {
@@ -466,6 +469,8 @@ static int set_screen_to_best_size(struct
vdagent_x11 *x11, int width, int heigh
void vdagent_x11_randr_handle_root_size_change(struct
vdagent_x11 *x11,
int screen, int width, int height)
{
+update_randr_res(x11, 0);
+
if (width == x11-width[screen] height ==
x11-height[screen]) {
return;
}
@@ -481,6 +486,33 @@ void
vdagent_x11_randr_handle_root_size_change(struct vdagent_x11 *x11,
}
}
+int vdagent_x11_randr_handle_event(struct vdagent_x11 *x11,
+XEvent event)
+{
+int handled = TRUE;
+
+switch (event.type - x11-xrandr_event_base) {
+case RRScreenChangeNotify: {
+XRRScreenChangeNotifyEvent *sce =
+(XRRScreenChangeNotifyEvent *) event;
+vdagent_x11_randr_handle_root_size_change(x11, 0,
+sce-width, sce-height);
+break;
+}
+case RRNotify: {
+update_randr_res(x11, 0);
+if (!x11-dont_send_guest_xorg_res)
+vdagent_x11_send_daemon_guest_xorg_res(x11, 1);
+break;
+}
+default:
+handled = FALSE;
+break;
+}
+
+return handled;
+}
+
static int min_int(int x, int y)
{
return x y ? y : x;
diff --git a/src/vdagent-x11.c
Re: [Spice-devel] Fwd: a question about Xspice
On 10/22/2014 11:37 AM, Hans de Goede wrote: Hi, Forwarding this to you guys from the xorg-devel list. Regards, Hans Forwarded Message Subject: a question about Xspice Date: Tue, 21 Oct 2014 17:30:54 +0800 (CST) From: cynthia cynthia_...@163.com To: xorg-de...@lists.x.org, x...@lists.x.org HI All, I am trying to build Xspice which is included in guest QXL driver, but one question confuses me a lot. As the Xspice's description in Readme, i get that Xspice is a X server and spice server in one, running in guest os, but our team has developed a set of windows virtual desktop in which the spiceserver is deployed in HOST os linked with QEMU, and i think that is coordinated with the spice protocol., So, could anyone explain it for me if spiceserver is deployed in guest os or host os? I will be very very appreciated~ For your virtual machines spice server is running in the host, i.e. in each qemu process. For Xspice the spice server is Xspice - it's a different configuration, there is no virtual machine, no host/guest distinction. Wherever Xspice is running, there the server is. Best Regards Cynthia ___ 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] unwatchable choppy performance using fullscreen flash in windows VM
On 10/16/2014 04:25 AM, Greg Sheremeta wrote: Hey all, Using a high-end Fedora 20 host, I get very poor choppy performance running flash full-screen in a Windows VM. I need to use Windows due to DRM stuff (nflsundayticket.tv). I've tried different virtual graphics adapters, but nothing helps. Attempting 1920x1080. Flash 15. Using remote-viewer or virt-manager, spice, QXL is set to 64 MB RAM. Some googling suggests that QXL just can't handle 1920x1080 flash fullscreen. Using VirtualBox gives pretty flawless performance at 1920x1080. But I want to use virt-manager / virt-viewer and KVM, of course :) I've also had success using VLC to stream the non-maximized flash player from the windows guest to the host, and then VLC scales up on the host (using host hardware acceleration, I think). But this is a bit of a pain to manage. One option I've read about is passing through a graphics adapter. My host machine has my primary nvidia card, but it also has the onboard Intel adapter that I don't use. Maybe if I can pass this Intel card through, I'd get the performance I'm looking for. From what I can tell, this isn't quite ready for primetime. I know about the 64bit vram bar, but I haven't tried it for this. Would it help? Any other ideas? Try turning off image compressoin: -spice image-compression=off,other options Thanks, Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gsher...@redhat.com ___ 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 xf86-qxl 1/2] Assert on QXL_INTERRUPT_ERROR
On 10/12/2014 03:24 PM, Marc-André Lureau wrote: From: Marc-Andre Lureau marcandre.lur...@redhat.com When qemu qxl device reaches a guest bug, it might set the QXL_INTERRUPT_ERROR interrupt flag, and stops processing guest commands. Therefore, it makes sense to check that flag in the guest and quit, instead of running in infinite loop in X and consuming CPU. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1151559 ACK both. Not sure about the assert though. --- src/qxl_io.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/qxl_io.c b/src/qxl_io.c index 8fa90b6..15fd678 100644 --- a/src/qxl_io.c +++ b/src/qxl_io.c @@ -43,9 +43,12 @@ qxl_wait_for_io_command (qxl_screen_t *qxl) ram_header = (void *)((unsigned long)qxl-ram + qxl-rom-ram_header_offset); -while (!(ram_header-int_pending QXL_INTERRUPT_IO_CMD)) +while (!(ram_header-int_pending + (QXL_INTERRUPT_IO_CMD | QXL_INTERRUPT_ERROR))) usleep (1); +assert(!(ram_header-int_pending QXL_INTERRUPT_ERROR)); + ram_header-int_pending = ~QXL_INTERRUPT_IO_CMD; } ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Wiki cleanup
On 09/29/2014 03:30 PM, Jeremy White wrote: If the idea seems sensible, then I'd propose that we work on the Wiki until we feel it stands mostly on it's own, and when we hit that point, we shift the main pages to reflect that. The website/wiki content needs some reorganization for sure, and the manual editing of the static website content needs to be improved. The next question is if we want to achieve that with a wiki, or by switching to a different 'CMS'. The wiki has the big advantage of being already there. I think Marc-André favoured http://jekyllrb.com for the static website part. Yeah, I worked a bit with Jekyll, and it was nice. I also find plain html + a nice css (e.g. bootstrap) surprisingly pleasant to work with. If we do keep a static component, I'd suggest we establish a git tree with git hooks that auto update (ala Github sites). And have patches and/or commit access to that tree be welcome. A git would probably have less spam :) Actually all of the non popular platforms are probably better (then again, mediawiki had good spam measures for a long time when Daniel was managing it). 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] protocol 2.0 document?
On 09/15/2014 05:30 AM, Brade-Atrust wrote: Hi guys, This is brade huang from taiwan, right now I try to dig into spice client source code and hopefully do some developments on spice, but when I investigated the code, I realized it already enhanced to protocol v2. I tried very hard to look for document about protocol v2 but couldn't get it. May you give me some suggestions about that? Thanks very much in advanced. There is no such thing as a v2 protocol. If by v2 you simply mean that the protocol as documented is not identical to the one currently used you are correct. But it has gone multiple small additions over time. The most succinct source is spice.proto in spice-common submodule: http://cgit.freedesktop.org/spice/spice-common/tree/spice.proto Sincerely, Brade ___ 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] Odd issue with OSX Guest
On 09/01/2014 09:01 PM, Brad Campbell wrote: G'day All, I'm attempting to run an OSX guest using spice as the remote display protocol (Yes, it's running on Apple hardware). The guest is using the standard vga driver. I'm using the latest git of spice, spice-gtk, qemu and the kernel. The issue I'm bumping up against is it appears something, somewhere is sending keypresses to the guest on a timed basis. I've not been able to put my finger on it, but things like pull down menus just cancel out from under me. It's almost like a second after the last mouse movement the escape key is being pressed. Being vaguely familiar enough with the source to be dangerous, is there an easy way for me to instrument keyboard/mouse events being sent to the guest? I can sprinkle the source with printf's, but I wondered if there was a better way of trying to find out where this is coming from. My gut says it must be spice related as it does not happen at all if I switch to vnc as the display. If you think the client is generating the presses do: export G_MESSAGES_DEBUG=all export SPICE_DEBUG=1 remote-viewer spice://host:port/ | grep key_event (messages are on stdout, not on stderr) Command line (in case it matters). qemu -enable-kvm -m 24576 -cpu core2duo -machine q35 \ -usb -device usb-kbd -device usb-mouse \ -device isa-applesmc,osk=xxx \ -smbios type=2 \ -device ide-drive,bus=ide.2,drive=MacHDD \ -drive id=MacHDD,if=none,file=/dev/sda3,cache=unsafe \ -monitor stdio \ -spice port=5930,disable-ticketing\ -vga std \ -net nic,model=virtio\ -net tap,ifname=tap0,script=/etc/qemu-ifup,vhost=on\ -smp 4,cores=4 \ -device ide-drive,bus=ide.4,drive=fatdrive \ -drive id=fatdrive,file=fat:ro:VirtIoNetDrv \ -kernel /home/brad/chameleon_svn2360_boot \ Outside of this issue, the guest is working well, but this peculiar behaviour has me a bit stumped. Regards, Brad ___ 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] [xf86-video-qxl] In XSpice mode, enable the ability to specify the various ram buffer sizes.
With agent running we do.
On August 22, 2014 7:55:19 AM EDT, Marc-André Lureau mlur...@redhat.com
wrote:
Hi Jeremy
I wish we could have dynamic allocation for Xspice, avoiding those
parameters, but this could be improved later.
Few remarks below:
- Original Message -
Also adjust the mode selection to fit, and add a few larger modes.
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
examples/spiceqxl.xorg.conf.example | 13 +
src/qxl.h |3 +++
src/qxl_driver.c| 19 +++
src/spiceqxl_driver.c | 33
+++--
src/spiceqxl_driver.h |7 +++
5 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/examples/spiceqxl.xorg.conf.example
b/examples/spiceqxl.xorg.conf.example
index be8a16b..8fd5d2f 100644
--- a/examples/spiceqxl.xorg.conf.example
+++ b/examples/spiceqxl.xorg.conf.example
@@ -96,6 +96,19 @@ Section Device
# defaults to 4
#Option NumHeads 4
+# The amount of frame buffer ram, in megabytes, to allocate
+# defaults to 16
+#Option FrameBufferSize 16
+
+# The amount of surface buffer ram, in megabytes, to allocate
+# Must be larger than FrameBufferSize
Is there a runtime check for that?
+# defaults to 128
+#Option SurfaceBufferSize 128
+
+# The amount of command buffer ram, in megabytes, to allocate
+# defaults to 128
+#Option CommandBufferSize 128
+
# Set Spice Agent Mouse
# defaults to false
#Option SpiceAgentMouse False
diff --git a/src/qxl.h b/src/qxl.h
index 19555ba..fa9b13f 100644
--- a/src/qxl.h
+++ b/src/qxl.h
@@ -154,6 +154,9 @@ enum {
OPTION_SPICE_VDAGENT_UINPUT_PATH,
OPTION_SPICE_VDAGENT_UID,
OPTION_SPICE_VDAGENT_GID,
+OPTION_FRAME_BUFFER_SIZE,
+OPTION_SURFACE_BUFFER_SIZE,
+OPTION_COMMAND_BUFFER_SIZE,
#endif
OPTION_COUNT,
};
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index d9bf447..87cdca4 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -146,6 +146,12 @@ const OptionInfoRec DefaultOptions[] =
SpiceVdagentUid, OPTV_INTEGER,{0}, FALSE},
{ OPTION_SPICE_VDAGENT_GID,
SpiceVdagentGid, OPTV_INTEGER,{0}, FALSE},
+{ OPTION_FRAME_BUFFER_SIZE,
+ FrameBufferSize, OPTV_INTEGER,
{DEFAULT_FRAME_BUFFER_SIZE}, FALSE},
+{ OPTION_SURFACE_BUFFER_SIZE,
+ SurfaceBufferSize,OPTV_INTEGER,
{DEFAULT_SURFACE_BUFFER_SIZE}, FALSE},
+{ OPTION_COMMAND_BUFFER_SIZE,
+ CommandBufferSize,OPTV_INTEGER,
{DEFAULT_COMMAND_BUFFER_SIZE}, FALSE},
#endif
{ -1, NULL, OPTV_NONE, {0}, FALSE }
@@ -190,11 +196,9 @@ unmap_memory_helper (qxl_screen_t *qxl)
static void
map_memory_helper (qxl_screen_t *qxl)
{
-qxl-ram = calloc (RAM_SIZE, 1);
-qxl-ram_size = RAM_SIZE;
+qxl-ram = calloc (qxl-ram_size, 1);
qxl-ram_physical = qxl-ram;
-qxl-vram = calloc (VRAM_SIZE, 1);
-qxl-vram_size = VRAM_SIZE;
+qxl-vram = calloc (qxl-vram_size, 1);
qxl-vram_physical = qxl-vram;
qxl-rom = calloc (ROM_SIZE, 1);
@@ -1081,6 +1085,13 @@ qxl_pre_init (ScrnInfoPtr pScrn, int flags)
strncpy(qxl-playback_fifo_dir, playback_fifo_dir,
sizeof(qxl-playback_fifo_dir));
else
qxl-playback_fifo_dir[0] = '\0';
+
+qxl-surface0_size =
+get_int_option (qxl-options, OPTION_FRAME_BUFFER_SIZE,
QXL_FRAME_BUFFER_SIZE) 20L;
+qxl-vram_size =
+get_int_option (qxl-options, OPTION_SURFACE_BUFFER_SIZE,
QXL_SURFACE_BUFFER_SIZE) 20L;
+qxl-ram_size =
+get_int_option (qxl-options, OPTION_COMMAND_BUFFER_SIZE,
QXL_COMMAND_BUFFER_SIZE) 20L;
#endif
if (!qxl_map_memory (qxl, scrnIndex))
diff --git a/src/spiceqxl_driver.c b/src/spiceqxl_driver.c
index 990467f..1561562 100644
--- a/src/spiceqxl_driver.c
+++ b/src/spiceqxl_driver.c
@@ -83,20 +83,18 @@ static QXLMode qxl_modes[] = {
QXL_MODE_EX(1600, 1200),
QXL_MODE_EX(1680, 1050),
QXL_MODE_EX(1920, 1080),
-#if VGA_RAM_SIZE = (16 * 1024 * 1024)
-/* these modes need more than 8 MB video memory */
QXL_MODE_EX(1920, 1200),
QXL_MODE_EX(1920, 1440),
QXL_MODE_EX(2048, 1536),
QXL_MODE_EX(2560, 1440),
QXL_MODE_EX(2560, 1600),
-#endif
-#if VGA_RAM_SIZE = (32 * 1024 * 1024)
-/* these modes need more than 16 MB video memory */
+QXL_MODE_EX(3840, 1080),
QXL_MODE_EX(2560, 2048),
QXL_MODE_EX(2800, 2100),
QXL_MODE_EX(3200, 2400),
-#endif
+QXL_MODE_EX(5760, 1080),
+QXL_MODE_EX(7680, 1080),
+
};
@@ -106,9 +104,8 @@ void init_qxl_rom(qxl_screen_t* qxl, uint32_t
rom_size)
QXLRom *rom = qxl-rom;
struct QXLModes *modes = (struct QXLModes *)(rom + 1);
uint32_t ram_header_size;
-uint32_t surface0_area_size;
uint32_t num_pages;
-
Re: [Spice-devel] [PATCH] [xf86-video-qxl] In XSpice mode, enable the ability to specify the various ram buffer sizes.
Sorry for top posting. I was replying to Marc-Andre's assertion. If the subject isnt arbitrary resolution, aka dynamic, continuous, then I missed it. If it is, since agent support for Xspice this feature works per my memory. On August 22, 2014 9:04:32 AM EDT, Jeremy White jwh...@codeweavers.com wrote: On 08/22/2014 07:52 AM, Alon Levy wrote: With agent running we do. ?? I'm sorry, I don't follow. Can you explain what you mean? Cheers, Jeremy On August 22, 2014 7:55:19 AM EDT, Marc-André Lureau mlur...@redhat.com wrote: Hi Jeremy I wish we could have dynamic allocation for Xspice, avoiding those parameters, but this could be improved later. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] [xf86-video-qxl] In XSpice mode, enable the ability to specify the various ram buffer sizes.
On August 22, 2014 9:16:31 AM EDT, Jeremy White jwh...@codeweavers.com wrote: On 08/22/2014 08:07 AM, Alon Levy wrote: Sorry for top posting. I was replying to Marc-Andre's assertion. If the subject isnt arbitrary resolution, aka dynamic, continuous, then I missed it. If it is, since agent support for Xspice this feature works per my memory. Ah, okay. Yes, my patch broke^H^H^H^H^Htouched x mode support, but the main emphasis was on configuring the ram buffer allocation; I think that's what Marc-Andre was referring to. (And dynamic resolutions do, in fact, work nicely with the agent turned on). Actually no excuse for the top post. I see. I like the idea of making sane memory allocation. When I ''fused'' Xspice I took what I thought was was simplest. I think you can replace mspace with malloc. There is no api to disable the address translation we do (i.e. memslots) but it's already equallity. I can't think of any other complication. Yes, the framebuffer is one allocation but it can be changed on every create primary, before it actually and after the destroy primary, with realloc. Maybe even the address can be changed, I think it could, but realloc takes care of that. I guess that has some cost though. Cheers, Jeremy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Bad display of the download-section on gitweb
On 08/06/2014 05:27 AM, Cody Chan wrote: Bad display of the download-section, http://cgit.freedesktop.org/spice/spice-gtk/ Tag Download v0.25 commit 31c099c931... v0.24 commit 6356941903... v0.23 commit 75176968b0... v0.22 commit 2e3aa29794... v0.21 commit 632836ed77... v0.20 commit 1d5717d8e2... v0.19 commit a879fd5cc4... v0.18 commit b63052b355... v0.17 commit c91b0488f4... v0.16 commit 4295363ccc... Actually, it's the the problem of the whole site. Can you try to explain what the exact problem is? ___ 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] Help with SmartCards and XSpice
On 08/06/2014 06:14 PM, Jeremy White wrote: And, finally, if that's all right - on to the next question: where should spiceccid fit in the XSpice stack? Should it be part of the Xorg driver? Should it be a vd_agent process? I'm not sure - I was thinking a third part, this time it's a bit more complicated, basically having a pcscd driver that would only be used by specific clients (i.e. processes, apps running presumably by the user controlling the Xspice instance). Usage scenario I guess is: 1. user launches Xspice (via some control interface) 2. user starts smartcard using app (i.e. firefox) 3. firefox connects to smartcard via pcscd, pcscd recognized this is supposed to go to the spice-ccid driver (to the *specific* one - you presumably have more then one instance of Xspice with different clients and hence smartcard hardware/credentials connected). You could use some environment variable, or perhaps having more then one instance of pcscd - that would make things simpler at the pcscd level, i.e. it could use a config file running only one driver, spice-ccid, with the correct unix domain socket connecting back to Xspice (spiceqxl_drv.so). Ah, okay, you're ahead of me. I hadn't gotten quite that far yet, but your thought process seems sound to me. Your thinking seems to suggest you feel the hook should be another fifo out of spiceqxl_drv.so. That would certainly be the easiest approach for me to take, so I have a built in desire to go that way. But I worry about complicating that driver. Why not route it through the vd_agent? vd_agent communicates with spiceqxl_drv.so via a pipe (or two? I forget - uinput and the vdagent protocol I mean). This would require one of 1. extending vd_agent protocol with the smartcard channel messages 2. using another pipe with smartcard channel messages And *then* you add a pipe / some other way of communicating from vd_agent to the pcscd driver (maybe you make the vdagent the driver, so it's loaded by pcscd.. no, doesn't sound like a good idea). Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Questions on usbredir + XSpice
On 08/06/2014 06:17 PM, Jeremy White wrote: I would advice against going for a protocol translater, your time would better spend on doing this properly right away. You don't think the kernel guys will push back, saying there is already an existing ip-to-usb device, and we should just use that one? I'm not a kernel guy so not suggesting this is a kernel opinion, but I don't think it's in the kernel. I wonder why. Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Help with SmartCards and XSpice
On 07/25/2014 12:01 AM, Jeremy White wrote: I think I have a tentative, but sufficient grasp of how the Smart Card stuff flows from the client into the server. It's not quite as clear how the server bridges it into qemu, but I think I have the gist of it. However, that doesn't work for XSpice sessions. I'm not sure why it shouldn't. The qemu portion simply forwards the ccid APDU's from the host. Spice has libcaccard which translates the CAC requests into calls against your PKCS #11 token on your client side. Alright, my ignorance is showing; perhaps I need to understand the qemu path better. In what I think of a typical use case, you have a client with a smart card reader attached. Let's say that is a Fedora 20 box. Then you have a host system which runs qemu to start a guest VM; let's say the host system is RHEL and the guest VM is Fedora RawHide. My understanding is that the client (essentially spice-gtk) interacts with the physical hardware, and uses libcacard to put the smartcard data onto the Spice smartcard channel. This is passed over the spice channel into qemu (running on the host), which uses the spice server calls to decode the data, and then it writes the data to a virtual character device that appears in the guest as a USB CCID device. RawHide detects that and treats it a 'real' hardware device. How am I doing so far? Is that about right? Yes. But just note that spice-server doesn't do anything except move bytes around. The actual protocols involved are: qemu: ccid protocol: usb smartcard reader spice-client via libcacard: smartcard In the XSpice case, we have no qemu. Instead, the host system runs Xorg against what is a virtual framebuffer, and runs the xf86-video-qxl xorg driver. In my use case, I've got Xorg running, with spice, and I'm just about to launch xdm. I'd really like to have a smartcard, if available, be part of the pam stack prior to launching xdm, so that it can be used by pam. Given that, how do you expect the smartcard data to flow into that Xorg session?I imagine that either the qxl driver, or a different utility (e.g. vd_agent) would be required in order to relay the smartcard data from the channel and into the pam stack. Is there something I'm missing? You are fine with only apps using pam_pkcs11 (i.e. anything using pam) using the smartcard? if so your direction makes sense. But the protocol is very low level for that - it passes what the CCID expects to get from the card. In the guest there is a CCID driver (there are multiple, but for coolkey I tested pcsclite http://pcsclite.alioth.debian.org/ccid.html ), which is consumed by coolkey via winscard.h and uses pcscd. There are a few things you can do: 1. same components, minus usb bus nss-libcacard-APDU-[:removed: ccid_device]-[:removed: usb bus]-[:removed: usb bus driver]-[:new: spiceccid pcsc module]-pcscd-pam_pkcs11/coolkey 2. new protocol - I guess you ruled that out already. 3. pam modlue consuming APDUs from card - what you proposed - same as 1 but using a pam module to consume the APDUs. It looks to me that this should be possible. My research suggests that pam_pkcs11 is pluggable, and that it should be possible to write a module that would receive the cert information. pam_pkcs11 uses plugable PKCS #11 modules (which also work in firefox and other NSS applications). You would have to install this module in your guest, however. I think redirecting the CCID USB data would be easier, though. Yeah, I saw that ccid was also pluggable, and I begin to see why that would be a better layer to plug into. (Saves me the hassle of parsing the cert data, right?) 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] [PATCH] Release 0.1.2
On 23.07.2014 14:40, Marc-André Lureau wrote: ack, thanks! Are you picking up this one for Fedora? The actual patches for any relevant bugs should already be there, doing a rebase will probably happen the next time someone needs to fix something (i.e. some bz). remote desktop fan club ___ 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] Release 0.1.2
On 07/24/2014 03:58 PM, poma wrote: On 24.07.2014 14:43, Alon Levy wrote: On 23.07.2014 14:40, Marc-André Lureau wrote: ack, thanks! Are you picking up this one for Fedora? The actual patches for any relevant bugs should already be there, doing a rebase will probably happen the next time someone needs to fix something (i.e. some bz). Is it not a sufficient reason the amount of patches per se? :) http://pkgs.fedoraproject.org/cgit/xorg-x11-drv-qxl.git/plain/ Touch. remote desktop fan club ___ 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] Release 0.1.2
Signed-off-by: Alon Levy al...@redhat.com --- NEWS | 10 ++ configure.ac | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 4ece9fe..86fe9f8 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,13 @@ +Major changes in 0.1.2 +== +Support for server managed fds +Xspice: use playback rate interface if available + +Bugs fixed: + 1030531 - drm: restore cursor after resolution change + fix cursor2 support in older kernels + FD 79317 - prevent crash on dual head systems + Major changes in 0.1.1 == diff --git a/configure.ac b/configure.ac index 01377a4..3ca32b6 100644 --- a/configure.ac +++ b/configure.ac @@ -23,7 +23,7 @@ # Initialize Autoconf AC_PREREQ([2.60]) AC_INIT([xf86-video-qxl], -[0.1.1], +[0.1.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [xf86-video-qxl]) AC_CONFIG_SRCDIR([Makefile.am]) -- 1.9.3 ___ 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.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, This release is mostly a bug fixing release, here is the NEWS excerpt: Major changes in 0.1.2 == Support for server managed fds Xspice: use playback rate interface if available Bugs fixed: 1030531 - drm: restore cursor after resolution change fix cursor2 support in older kernels FD 79317 - prevent crash on dual head systems Enjoy, Alon Alon Levy (11): tests/xspice_util.py: fix hardcoded port spiceqxl_spice_server: no need to call spice_server_set_noauth twice xspice: chown both files used by vdagent for suid Xorg case Xspice: cleanup non regular files too Xspice: fix cleanup when some processes are already dead Xspice: cleanup vdagent files spiceqxl_util.[hc]: add copyright license headers Xspice: add better doc strings for audio vdagent qxl_image.c: fix compilation break qxl_driver.c: fix compiler warning 'defined but not used' qxl_kernel_mode_enabled Release 0.1.2 Dave Airlie (1): qxl: fix set cursor2 support for older kernel David Mansfield (1): Dynamically adjust chunk size to avoid command buffer overflow. Hans de Goede (3): Add support for XSERVER_PLATFORM_BUS Fix qxl_driver_func to adhere to the API Add support for server managed fds Jeremy White (1): Make use of the new playback rate interface, if available. Marc-André Lureau (1): drm: restore cursor after resolution change longguang.yue (1): fix memory leak when alloc uxa git tag: xf86-video-qxl-0.1.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-qxl-0.1.2.tar.bz2 MD5: 6a645acb2c462c09b94cd926ca401a86 xf86-video-qxl-0.1.2.tar.bz2 SHA1: 58f007117e4f3a0bdd21ce1387526664b9215ed9 xf86-video-qxl-0.1.2.tar.bz2 SHA256: 43a7d1e7b60ae32941b6a4359e26de01941012d717d7a7747affd379debc5227 xf86-video-qxl-0.1.2.tar.bz2 PGP: http://xorg.freedesktop.org/archive/individual/driver/xf86-video-qxl-0.1.2.tar.bz2.sig http://xorg.freedesktop.org/archive/individual/driver/xf86-video-qxl-0.1.2.tar.gz MD5: 17e869afe5f8d1e279529c9bcc1d713f xf86-video-qxl-0.1.2.tar.gz SHA1: d530e9d23cf2fb9859489cb0e26c6afbff4c9be8 xf86-video-qxl-0.1.2.tar.gz SHA256: a11fbc2231c0a3db37bbc263ec07f4dc01ab0be23139f417b0c1a77ea8445f17 xf86-video-qxl-0.1.2.tar.gz PGP: http://xorg.freedesktop.org/archive/individual/driver/xf86-video-qxl-0.1.2.tar.gz.sig -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTz8LDAAoJEGSFt2Lm6PXuyX4H/1+dT1Y09UgDuPI0EltcaFzu Puchv90NgVQkNlWeY+EI8GZb/lyag2DRp0GDzkHuUwFAPS2CvEbI6MIvmqvbHnOQ 7aDgwR8dQLOkih6uzHR+jskGL9L9D/E+SuALEC98hj6WQz/m7HU2tMID/1u9F8XA nsq+m+zikk3h2zaokOtb+VJ0pqs5mPlIWIIbPv/7duau5GitYyd+z+s0fdziUZ20 7czvRSq7eKIX3EThjXNC+bugU+nyxezg0jGP/KSPzH7VzQTIbLBAR+gJHHLP5i0L tYiH+4pw+GElU1u6y8h1OmIx3GoBMb6c2UiQF7kpGXi0XjA9uXpNEotY/L97mDE= =3ZFC -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [vdagent-linux 2/2] Handle STRING selection type
This is to please vncviewer.
https://bugzilla.redhat.com/show_bug.cgi?id=1117764
ACK
---
src/vdagent-x11-priv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/vdagent-x11-priv.h b/src/vdagent-x11-priv.h
index 4a5729b..38f852e 100644
--- a/src/vdagent-x11-priv.h
+++ b/src/vdagent-x11-priv.h
@@ -64,8 +64,8 @@ struct monitor_size {
};
static const struct clipboard_format_tmpl clipboard_format_templates[] = {
-{ VD_AGENT_CLIPBOARD_UTF8_TEXT, { UTF8_STRING,
- text/plain;charset=UTF-8, text/plain;charset=utf-8, NULL }, },
+{ VD_AGENT_CLIPBOARD_UTF8_TEXT, { UTF8_STRING,
text/plain;charset=UTF-8,
+ text/plain;charset=utf-8, STRING, NULL }, },
{ VD_AGENT_CLIPBOARD_IMAGE_PNG, { image/png, NULL }, },
{ VD_AGENT_CLIPBOARD_IMAGE_BMP, { image/bmp, image/x-bmp,
image/x-MS-bmp, image/x-win-bitmap, NULL }, },
--
1.9.3
___
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] [vdagent-linux 1/2] Reply to TIMESTAMP requests
This is to please vncviewer.
Commit message can say 'add TIMESTAMP handling'. ACK.
btw wrt the TODO, xsel seems to do the same as you.
https://bugzilla.redhat.com/show_bug.cgi?id=1117764
---
src/vdagent-x11-priv.h | 1 +
src/vdagent-x11.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/src/vdagent-x11-priv.h b/src/vdagent-x11-priv.h
index c607850..4a5729b 100644
--- a/src/vdagent-x11-priv.h
+++ b/src/vdagent-x11-priv.h
@@ -83,6 +83,7 @@ struct vdagent_x11 {
Atom targets_atom;
Atom incr_atom;
Atom multiple_atom;
+Atom timestamp_atom;
Window root_window[MAX_SCREENS];
Window selection_window;
struct udscs_connection *vdagentd;
diff --git a/src/vdagent-x11.c b/src/vdagent-x11.c
index c5d54ac..752b337 100644
--- a/src/vdagent-x11.c
+++ b/src/vdagent-x11.c
@@ -218,6 +218,7 @@ struct vdagent_x11 *vdagent_x11_create(struct
udscs_connection *vdagentd,
x11-targets_atom = XInternAtom(x11-display, TARGETS, False);
x11-incr_atom = XInternAtom(x11-display, INCR, False);
x11-multiple_atom = XInternAtom(x11-display, MULTIPLE, False);
+x11-timestamp_atom = XInternAtom(x11-display, TIMESTAMP, False);
for(i = 0; i clipboard_format_count; i++) {
x11-clipboard_formats[i].type = clipboard_format_templates[i].type;
for(j = 0; clipboard_format_templates[i].atom_names[j]; j++) {
@@ -1036,6 +1037,20 @@ static void
vdagent_x11_handle_selection_request(struct vdagent_x11 *x11)
return;
}
+if (event-xselectionrequest.target == x11-timestamp_atom) {
+/* TODO: use more accurate selection time */
+guint32 timestamp = event-xselectionrequest.time;
+
+XChangeProperty(x11-display, event-xselectionrequest.requestor,
+ event-xselectionrequest.property,
+event-xselectionrequest.target, 32,
PropModeReplace,
+(guint8*)timestamp, 1);
+vdagent_x11_send_selection_notify(x11,
+ event-xselectionrequest.property, NULL);
+ return;
+}
+
+
if (event-xselectionrequest.target == x11-targets_atom) {
vdagent_x11_send_targets(x11, selection, event);
return;
--
1.9.3
___
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 (v2)] Make sure the child is able to connect to the X server before exiting the mainline.
On 07/09/2014 10:08 PM, Jeremy White wrote:
This allows the vdagent to be used in the Xsetup phase of an xdm session;
otherwise, it's X11 connection fails because of the greeter display grab.
The issue is that we daemonize before attempting the X connection.
We then immediately exit the main process; xdm then goes on to invoke the
greeter which performs an exclusive grab on the X server, so the child
connection fails.
The change is to have the main process wait for up to 10 seconds for an 'all
clear'
message from the client. This lets us return a correct status on a real X
error, as well as letting our child successfully connect to the X server.
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
Pushed together with the previous two v1 patches.
src/vdagent.c | 50 --
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/src/vdagent.c b/src/vdagent.c
index d7f7aba..905ff5b 100644
--- a/src/vdagent.c
+++ b/src/vdagent.c
@@ -35,6 +35,7 @@
#include sys/stat.h
#include spice/vd_agent.h
#include glib.h
+#include poll.h
#include udscs.h
#include vdagentd-proto.h
@@ -151,9 +152,34 @@ static void quit_handler(int sig)
quit = 1;
}
-void daemonize(void)
+/* When we daemonize, it is useful to have the main process
+ wait to make sure the X connection worked. We wait up
+ to 10 seconds to get an 'all clear' from the child
+ before we exit. If we don't, we're able to exit with a
+ status that indicates an error occured */
+void wait_and_exit(int s)
{
-int x, retval = 0;
+char buf[4];
+struct pollfd p;
+p.fd = s;
+p.events = POLLIN;
+
+if (poll(p, 1, 1) 0)
+if (read(s, buf, sizeof(buf)) 0)
+exit(0);
+
+exit(1);
+}
+
+int daemonize(void)
+{
+int x;
+int fd[2];
+
+if (socketpair(PF_LOCAL, SOCK_STREAM, 0, fd)) {
+syslog(LOG_ERR, socketpair : %s, strerror(errno));
+exit(1);
+}
/* detach from terminal */
switch (fork()) {
@@ -161,13 +187,17 @@ void daemonize(void)
close(0); close(1); close(2);
setsid();
x = open(/dev/null, O_RDWR); x = dup(x); x = dup(x);
-break;
+close(fd[0]);
+return fd[1];
case -1:
syslog(LOG_ERR, fork: %s, strerror(errno));
-retval = 1;
+exit(1);
default:
-exit(retval);
+close(fd[1]);
+wait_and_exit(fd[0]);
}
+
+return 0;
}
static int file_test(const char *path)
@@ -182,6 +212,7 @@ int main(int argc, char *argv[])
fd_set readfds, writefds;
int c, n, nfds, x11_fd;
int do_daemonize = 1;
+int parent_socket = 0;
int x11_sync = 0;
struct sigaction act;
@@ -236,7 +267,7 @@ int main(int argc, char *argv[])
}
if (do_daemonize)
-daemonize();
+parent_socket = daemonize();
reconnect:
if (version_mismatch) {
@@ -275,6 +306,13 @@ reconnect:
vdagent_file_xfers = vdagent_file_xfers_create(client, fx_dir,
fx_open_dir, debug);
+if (parent_socket) {
+if (write(parent_socket, OK, 2) != 2)
+syslog(LOG_WARNING, Parent already gone.);
+close(parent_socket);
+parent_socket = 0;
+}
+
while (client !quit) {
FD_ZERO(readfds);
FD_ZERO(writefds);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Setting colour depths
On 06/23/2014 06:59 PM, Damien Dye wrote: Hi all am testing Xspice to replace VNC at our company an have some questions I can't seam to solve 1) when I set the color depth in the config file to 16 the server fails to start saying it's unsupported. I never tried it. Seems sensible - I guess you are trying to reduce bandwidth? 2) is it possible for a user no root to open a persistent session and the system to return back to the shell when the sessions start ? yes, you can run Xspice as non root. Actually recent Xorg can run itself as a non root user, but I haven't tried that combo. But since Xspice never needed access to any root only resource (i.e. /dev/mem) it isn't a problem. What is the specific problem you are having running it? regards -- Damien Dye IT Manager *Sondrel Ltd* Sondrel House, Theale Lakes Business Park Moulden Way, Sulhamstead, Berkshire, RG7 4GB, UK Tel: +44(0)118 9838 550 www.sondrel.com [image: Sondrel] http://www.sondrel.com/ This e-mail and any attachments may be confidential or legally privileged. If you are not the intended recipient, you should destroy the e-mail message and any attachments, and inform us of the erroneous delivery by return e-mail. You are prohibited from retaining, distributing, disclosing or using any information contained herein. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Sondrel Ltd and the sender do not accept liability for any errors or omissions, nor do we accept liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is consequently confirmed in writing under the personal signature of a duly authorised officer of Sondrel Ltd. This email is sent on behalf of Sondrel Ltd registered in England with number 4491953, registered office Sondrel House, Theale Lakes Business Park, Moulden Way, Sulhamstead, Berkshire, RG7 4GB, UK. ___ 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 xf86-qxl] drm: restore cursor after resolution change
On 07/02/2014 01:22 PM, Marc-André Lureau wrote: From: Marc-André Lureau marcandre.lur...@gmail.com The Spice server qemu reset the cursor state when changing resolution. Although X does restore the cursor on framebuffer changes, it doesn't for crtc config. Restoring the cursor here is the simplest way to solve the invisible cursor after resolution change bug with DRM driver. ACK. https://bugzilla.redhat.com/show_bug.cgi?id=1030531 --- src/qxl_drmmode.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/qxl_drmmode.c b/src/qxl_drmmode.c index af4b22d..f9eca5f 100644 --- a/src/qxl_drmmode.c +++ b/src/qxl_drmmode.c @@ -47,6 +47,9 @@ #include qxl.h #include qxl_surface.h + +static void drmmode_show_cursor (xf86CrtcPtr crtc); + static void drmmode_ConvertFromKMode(ScrnInfoPtr scrn, drmModeModeInfo *kmode, @@ -248,6 +251,10 @@ done: crtc-active = TRUE; #endif +CursorPtr cursor = xf86_config-cursor; +if (cursor) +drmmode_show_cursor(crtc); + return ret; } ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [vdagentd] Add an explicit switch to signal fake uinput devices.
On 06/23/2014 11:41 PM, Jeremy White wrote:
ACK
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
src/vdagentd.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/vdagentd.c b/src/vdagentd.c
index 1098fb6..fa47997 100644
--- a/src/vdagentd.c
+++ b/src/vdagentd.c
@@ -756,6 +756,7 @@ static void usage(FILE *fp)
-s port set virtio serial port [%s]\n
-S filename set udcs socket [%s]\n
-u dev set uinput device [%s]\n
+ -f treat uinput device as fake; no ioctls\n
-x don't daemonize\n
#ifdef HAVE_CONSOLE_KIT
-X Disable console kit integration\n
@@ -865,7 +866,7 @@ int main(int argc, char *argv[])
struct sigaction act;
for (;;) {
-if (-1 == (c = getopt(argc, argv, -dhxXs:u:S:)))
+if (-1 == (c = getopt(argc, argv, -dhxXfs:u:S:)))
break;
switch (c) {
case 'd':
@@ -880,6 +881,9 @@ int main(int argc, char *argv[])
case 'u':
uinput_device = optarg;
break;
+case 'f':
+uinput_fake = 1;
+break;
case 'x':
do_daemonize = 0;
break;
@@ -896,11 +900,6 @@ int main(int argc, char *argv[])
}
}
-if (strncmp(uinput_device, /dev, 4) != 0) {
-syslog(LOG_INFO, using fake uinput);
-uinput_fake = 1;
-}
-
memset(act, 0, sizeof(act));
act.sa_flags = SA_RESTART;
act.sa_handler = quit_handler;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [vdagent] Make sure the child is able to connect to the X server before exiting the mainline.
On 06/24/2014 12:05 AM, Jeremy White wrote:
This allows the vdagent to be used in the Xsetup phase of an xdm session;
otherwise, its X11 connection fails because of the greeter display grab.
relies on the fact the socketpair fd's are never 0 (i.e. fd[1] below is
never 0). Which I think is wrong, but only if you close the default fd
0, which you won't, so fine by me.
ACK.
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
src/vdagent.c | 50 --
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/src/vdagent.c b/src/vdagent.c
index d7f7aba..905ff5b 100644
--- a/src/vdagent.c
+++ b/src/vdagent.c
@@ -35,6 +35,7 @@
#include sys/stat.h
#include spice/vd_agent.h
#include glib.h
+#include poll.h
#include udscs.h
#include vdagentd-proto.h
@@ -151,9 +152,34 @@ static void quit_handler(int sig)
quit = 1;
}
-void daemonize(void)
+/* When we daemonize, it is useful to have the main process
+ wait to make sure the X connection worked. We wait up
+ to 10 seconds to get an 'all clear' from the child
+ before we exit. If we don't, we're able to exit with a
+ status that indicates an error occured */
+void wait_and_exit(int s)
{
-int x, retval = 0;
+char buf[4];
+struct pollfd p;
+p.fd = s;
+p.events = POLLIN;
+
+if (poll(p, 1, 1) 0)
+if (read(s, buf, sizeof(buf)) 0)
+exit(0);
+
+exit(1);
+}
+
+int daemonize(void)
+{
+int x;
+int fd[2];
+
+if (socketpair(PF_LOCAL, SOCK_STREAM, 0, fd)) {
+syslog(LOG_ERR, socketpair : %s, strerror(errno));
+exit(1);
+}
/* detach from terminal */
switch (fork()) {
@@ -161,13 +187,17 @@ void daemonize(void)
close(0); close(1); close(2);
setsid();
x = open(/dev/null, O_RDWR); x = dup(x); x = dup(x);
-break;
+close(fd[0]);
+return fd[1];
case -1:
syslog(LOG_ERR, fork: %s, strerror(errno));
-retval = 1;
+exit(1);
default:
-exit(retval);
+close(fd[1]);
+wait_and_exit(fd[0]);
}
+
+return 0;
}
static int file_test(const char *path)
@@ -182,6 +212,7 @@ int main(int argc, char *argv[])
fd_set readfds, writefds;
int c, n, nfds, x11_fd;
int do_daemonize = 1;
+int parent_socket = 0;
int x11_sync = 0;
struct sigaction act;
@@ -236,7 +267,7 @@ int main(int argc, char *argv[])
}
if (do_daemonize)
-daemonize();
+parent_socket = daemonize();
reconnect:
if (version_mismatch) {
@@ -275,6 +306,13 @@ reconnect:
vdagent_file_xfers = vdagent_file_xfers_create(client, fx_dir,
fx_open_dir, debug);
+if (parent_socket) {
+if (write(parent_socket, OK, 2) != 2)
+syslog(LOG_WARNING, Parent already gone.);
+close(parent_socket);
+parent_socket = 0;
+}
+
while (client !quit) {
FD_ZERO(readfds);
FD_ZERO(writefds);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [vdagent] Make sure the child is able to connect to the X server before exiting the mainline.
On 06/24/2014 12:05 AM, Jeremy White wrote:
This allows the vdagent to be used in the Xsetup phase of an xdm session;
otherwise, its X11 connection fails because of the greeter display grab.
But could you make the comment contain the discussion where you
explained this in more detail?
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
src/vdagent.c | 50 --
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/src/vdagent.c b/src/vdagent.c
index d7f7aba..905ff5b 100644
--- a/src/vdagent.c
+++ b/src/vdagent.c
@@ -35,6 +35,7 @@
#include sys/stat.h
#include spice/vd_agent.h
#include glib.h
+#include poll.h
#include udscs.h
#include vdagentd-proto.h
@@ -151,9 +152,34 @@ static void quit_handler(int sig)
quit = 1;
}
-void daemonize(void)
+/* When we daemonize, it is useful to have the main process
+ wait to make sure the X connection worked. We wait up
+ to 10 seconds to get an 'all clear' from the child
+ before we exit. If we don't, we're able to exit with a
+ status that indicates an error occured */
+void wait_and_exit(int s)
{
-int x, retval = 0;
+char buf[4];
+struct pollfd p;
+p.fd = s;
+p.events = POLLIN;
+
+if (poll(p, 1, 1) 0)
+if (read(s, buf, sizeof(buf)) 0)
+exit(0);
+
+exit(1);
+}
+
+int daemonize(void)
+{
+int x;
+int fd[2];
+
+if (socketpair(PF_LOCAL, SOCK_STREAM, 0, fd)) {
+syslog(LOG_ERR, socketpair : %s, strerror(errno));
+exit(1);
+}
/* detach from terminal */
switch (fork()) {
@@ -161,13 +187,17 @@ void daemonize(void)
close(0); close(1); close(2);
setsid();
x = open(/dev/null, O_RDWR); x = dup(x); x = dup(x);
-break;
+close(fd[0]);
+return fd[1];
case -1:
syslog(LOG_ERR, fork: %s, strerror(errno));
-retval = 1;
+exit(1);
default:
-exit(retval);
+close(fd[1]);
+wait_and_exit(fd[0]);
}
+
+return 0;
}
static int file_test(const char *path)
@@ -182,6 +212,7 @@ int main(int argc, char *argv[])
fd_set readfds, writefds;
int c, n, nfds, x11_fd;
int do_daemonize = 1;
+int parent_socket = 0;
int x11_sync = 0;
struct sigaction act;
@@ -236,7 +267,7 @@ int main(int argc, char *argv[])
}
if (do_daemonize)
-daemonize();
+parent_socket = daemonize();
reconnect:
if (version_mismatch) {
@@ -275,6 +306,13 @@ reconnect:
vdagent_file_xfers = vdagent_file_xfers_create(client, fx_dir,
fx_open_dir, debug);
+if (parent_socket) {
+if (write(parent_socket, OK, 2) != 2)
+syslog(LOG_WARNING, Parent already gone.);
+close(parent_socket);
+parent_socket = 0;
+}
+
while (client !quit) {
FD_ZERO(readfds);
FD_ZERO(writefds);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk] session: prefix proxy lookup errors
On 07/03/2014 07:49 PM, Marc-André Lureau wrote:
Proxy errors are already reported with G_IO_ERROR_PROXY messages,
however proxy name lookup error can be more detailed.
ACK
https://bugzilla.redhat.com/show_bug.cgi?id=1115986
---
gtk/spice-session.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gtk/spice-session.c b/gtk/spice-session.c
index fed57a4..7aef787 100644
--- a/gtk/spice-session.c
+++ b/gtk/spice-session.c
@@ -1730,6 +1730,7 @@ static void proxy_lookup_ready(GObject *source_object,
GAsyncResult *result,
addresses = g_resolver_lookup_by_name_finish(G_RESOLVER(source_object),
result, open_host-error);
if (addresses == NULL || open_host-error) {
+g_prefix_error(open_host-error, SPICE proxy: );
coroutine_yieldto(open_host-from, NULL);
return;
}
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [vdagentd] Add an option such that the daemon will exit after processing a single session.
On 06/24/2014 12:05 AM, Jeremy White wrote:
ACK
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
src/vdagentd.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/vdagentd.c b/src/vdagentd.c
index fa47997..b5c7d14 100644
--- a/src/vdagentd.c
+++ b/src/vdagentd.c
@@ -59,6 +59,7 @@ static const char *vdagentd_socket = VDAGENTD_SOCKET;
static const char *uinput_device = /dev/uinput;
static int debug = 0;
static int uinput_fake = 0;
+static int only_once = 0;
static struct udscs_server *server = NULL;
static struct vdagent_virtio_port *virtio_port = NULL;
static GHashTable *active_xfers = NULL;
@@ -758,6 +759,7 @@ static void usage(FILE *fp)
-u dev set uinput device [%s]\n
-f treat uinput device as fake; no ioctls\n
-x don't daemonize\n
+ -o Only handle one virtio serial session.\n
#ifdef HAVE_CONSOLE_KIT
-X Disable console kit integration\n
#endif
@@ -798,6 +800,7 @@ void main_loop(void)
fd_set readfds, writefds;
int n, nfds;
int ck_fd = 0;
+int once = 0;
while (!quit) {
FD_ZERO(readfds);
@@ -827,6 +830,7 @@ void main_loop(void)
udscs_server_handle_fds(server, readfds, writefds);
if (virtio_port) {
+once = 1;
vdagent_virtio_port_handle_fds(virtio_port, readfds,
writefds);
if (!virtio_port) {
int old_client_connected = client_connected;
@@ -845,6 +849,11 @@ void main_loop(void)
client_connected = old_client_connected;
}
}
+else if (only_once once)
+{
+syslog(LOG_INFO, Exiting after one client session.);
+break;
+}
if (session_info FD_ISSET(ck_fd, readfds)) {
active_session = session_info_get_active_session(session_info);
@@ -866,7 +875,7 @@ int main(int argc, char *argv[])
struct sigaction act;
for (;;) {
-if (-1 == (c = getopt(argc, argv, -dhxXfs:u:S:)))
+if (-1 == (c = getopt(argc, argv, -dhxXfos:u:S:)))
break;
switch (c) {
case 'd':
@@ -884,6 +893,9 @@ int main(int argc, char *argv[])
case 'f':
uinput_fake = 1;
break;
+case 'o':
+only_once = 1;
+break;
case 'x':
do_daemonize = 0;
break;
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] qxl_driver.c: fix compiler warning 'defined but not used' qxl_kernel_mode_enabled
On Mon, Jun 09, 2014 at 04:08:37PM +0300, Alon Levy wrote:
Signed-off-by: Alon Levy al...@redhat.com
---
src/qxl_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index b9aa0e9..d9bf447 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -1242,7 +1242,7 @@ qxl_init_scrn (ScrnInfoPtr pScrn, Bool kms)
pScrn-ValidMode= NULL;
}
-#ifdef XF86DRM_MODE
+#if defined(XF86DRM_MODE) !defined(XSPICE)
static char *
CreatePCIBusID(const struct pci_device *dev)
{
--
1.9.3
ACK, though we could also ensure that XF86DRM_MODE is never defined when
XSPICE is ?
You're right, but it's more work - mainly deciding what I want done - should
configure not allow both drm and xspice? probably. Later patch?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] qxl_image.c: fix compilation break
Since 3d511c30206bd8c9a207c436186a03af0bb02962 Xspice building is broken
due to undefined MAX_RELOCS when not building with XF86DRM_MODE.
---
src/qxl_image.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/qxl_image.c b/src/qxl_image.c
index eb66b63..8927fd4 100644
--- a/src/qxl_image.c
+++ b/src/qxl_image.c
@@ -159,6 +159,7 @@ qxl_image_create (qxl_screen_t *qxl, const uint8_t *data,
chunk_size = MAX (512 * 512, dest_stride);
+#ifdef XF86DRM_MODE
/* ensure we will not create too many pieces and overflow
* the command buffer (MAX_RELOCS). if so, increase the chunk_size.
* each loop creates at least 2 cmd buffer entries, and
@@ -170,6 +171,7 @@ qxl_image_create (qxl_screen_t *qxl, const uint8_t *data,
ErrorF (adjusted chunk_size to %d\n, chunk_size);
#endif
}
+#endif
while (h)
{
--
1.9.3
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 0/2] stability for dual head
On 06/17/2014 04:08 PM, David Mansfield wrote: On 06/17/2014 03:24 AM, Alon Levy wrote: On 06/16/2014 04:16 PM, David Mansfield wrote: On 06/09/2014 09:29 AM, Alon Levy wrote: On 06/09/2014 04:18 PM, David Mansfield wrote: On 06/09/2014 07:18 AM, Alon Levy wrote: On 06/03/2014 04:14 PM, David Mansfield wrote: Bump. I'll make it easy. This is a multiple choice response form. Anyone reading this can respond with one letter so save time and effort. a) We're too busy with RHEL 7/paying clients, come back in a month/some timeframe b) There's an SEP field on these problems, everyone who understands that code has moved on c) Go away d) Oops, I've been meaning to get back to you but I keep forgetting and life is hectic... e) Didn't you hear? SPICE is dead. f) Other. Please elaborate using the space provided below: The first patch looks good (just adjusting the #if to disable the print). I'll pick it up, thanks, you deserved a faster response. No idea what SEP is. Hi Alon, I followed Marc-André's advice and sent these out to DRI ond xorg mailing lists, respectively. The qxl.ko patch was picked up by Dave Airlie and committed to drm-next branch. The second is still without a home. (BTW: An SEP is a somebody else's problem effect, see http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem, popularized in Douglas Adams' Hitchhiker's Guide novel. Very funny concept.) Missed that. Any possibility of help with issue #2, the xorg-devel list is silent on this one and I don't know who the maintainer is specifically. Without this patch xorg-qxl is trivially crashable when using dual head at 1920x1200 resolution (or potentially lower resolution). 96 relocs with 512x512 chunks - what do you do to crash it? Soren Sandmann is the maintainer, but I did a release once, I can commit it once I'm done testing (need to allow large resolutions which by default are limited to surface0_area_size). Good morning (evening?) Alon, Anything else you need from me on this? I've attached the patch from git-format-patch that should have all of the correct signed-off etc. and a proper commit description. Just a friendly ping. Thanks. I pushed your patch (plus just a white space fix). It is still not testable without changing the surface0 allocation manually or enabling surface resizing. Have you taken a look perhaps at the surface resize stuff? how did you test it so far? Not sure what you mean by surface0 allocation, I'm referring to some currently disabled (preprocessor macro) code, but on second thought it is not required. but here's my environment where I can 100% reproduce this issue: - F20 host ,F20 guest, F20 client (all same box) - In the libvirt domain xml, a few tweks to increase memory available to qxl video framebuffer from 16mb to 32mb in domain xml: video model type='qxl' ram='131072' vram='131072' heads='1'/ /video qemu:commandline qemu:arg value='-global'/ qemu:arg value='qxl-vga.vgamem_mb=32'/ /qemu:commandline - run MATE desktop in guest, not sure if this is necessary or not, but it's what I use - use two (virtual and physical) monitors with 1920x1200 resolution (24 bit color depth). You will need either a patched kernel (or a 3.16 kernel), or a patched remote-viewer because of a different bug which is fixed in qxl.ko in latest kernel or else the second monitor may show entire framebuffer instead of monitor 2 area. At this point shutter will crash the system when doing a screenshot using the selection feature, as will opening the second virtual monitor with the saved monitor configuration in .config/monitors.xml. I appreciate your help getting this in! Still need to do a release. Thanks, David ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 0/2] stability for dual head
On 06/16/2014 04:16 PM, David Mansfield wrote: On 06/09/2014 09:29 AM, Alon Levy wrote: On 06/09/2014 04:18 PM, David Mansfield wrote: On 06/09/2014 07:18 AM, Alon Levy wrote: On 06/03/2014 04:14 PM, David Mansfield wrote: Bump. I'll make it easy. This is a multiple choice response form. Anyone reading this can respond with one letter so save time and effort. a) We're too busy with RHEL 7/paying clients, come back in a month/some timeframe b) There's an SEP field on these problems, everyone who understands that code has moved on c) Go away d) Oops, I've been meaning to get back to you but I keep forgetting and life is hectic... e) Didn't you hear? SPICE is dead. f) Other. Please elaborate using the space provided below: The first patch looks good (just adjusting the #if to disable the print). I'll pick it up, thanks, you deserved a faster response. No idea what SEP is. Hi Alon, I followed Marc-André's advice and sent these out to DRI ond xorg mailing lists, respectively. The qxl.ko patch was picked up by Dave Airlie and committed to drm-next branch. The second is still without a home. (BTW: An SEP is a somebody else's problem effect, see http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem, popularized in Douglas Adams' Hitchhiker's Guide novel. Very funny concept.) Missed that. Any possibility of help with issue #2, the xorg-devel list is silent on this one and I don't know who the maintainer is specifically. Without this patch xorg-qxl is trivially crashable when using dual head at 1920x1200 resolution (or potentially lower resolution). 96 relocs with 512x512 chunks - what do you do to crash it? Soren Sandmann is the maintainer, but I did a release once, I can commit it once I'm done testing (need to allow large resolutions which by default are limited to surface0_area_size). Good morning (evening?) Alon, Anything else you need from me on this? I've attached the patch from git-format-patch that should have all of the correct signed-off etc. and a proper commit description. Just a friendly ping. Thanks. I pushed your patch (plus just a white space fix). It is still not testable without changing the surface0 allocation manually or enabling surface resizing. Have you taken a look perhaps at the surface resize stuff? how did you test it so far? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] how to read the spice-server source code?
On 05/29/2014 11:16 AM, aaron_0119 wrote: hi, guys, i built the spice-gtk on an arm board(Contex A9). i test it and found that it is not very smoothly when i playing the video. so i decided to how the video streamer be transmitted or compressed between the server and client. i try to read the source code but i found the spice-server source code is very trival and hard to follow. plz give me some suggestion to do this?which file should i read first?the red_worker.c or the reds.c or others? And If you have some idea to improve the performance of the client on ARM, you can send it to me,too. thx a lot~ best regard to you ~ Aaron Zhang red_worker contains the whole of the display channel logic, including video detection. Spice doesn't passthrough video streams from the app in the vm to the client, it recompresses decoded images using a heuristic (framerate / same area / large enough). mjpeg code is separate in mjpeg_encoder.c reds.c is the server itself, not interesting for you I think. Channel logic is in red_channel.c ___ 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 spice-protocol] RFC: Add VD_AGENT_CAP_ANY_SELECTION_TYPE
On 06/04/2014 07:45 PM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
When both the client and the agent advertize
VD_AGENT_CAP_ANY_SELECTION_TYPE capability, the existing
VDAgentClipboard messages are modified to embed string
representation of the selection mime type.
Handling arbitrary mime types allows to describe any selection data
type, instead of a limited fixed list. The approach to reuse the integer
representation to extend the type with a registry (like X's atoms) has
been discarded (too complicated without substential benefits)
A string is a \0 terminated utf8 byte array: foo\0
A string[] is a \0\0 terminated array of utf8 strings: foo\0bar\0\0.
So no null strings in the list? sounds fine to me (just need to verify
this in code).
And the client will need to handle window system specific changes? or
can it pass the mime types on without looking at them?
---
spice/vd_agent.h | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/spice/vd_agent.h b/spice/vd_agent.h
index 7464661..2e24c87 100644
--- a/spice/vd_agent.h
+++ b/spice/vd_agent.h
@@ -161,15 +161,6 @@ enum {
VD_AGENT_ERROR,
};
-typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
-#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
-uint8_t selection;
-uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
-#endif
-uint32_t type;
-uint8_t data[0];
-} VDAgentClipboard;
-
enum {
VD_AGENT_CLIPBOARD_NONE = 0,
VD_AGENT_CLIPBOARD_UTF8_TEXT,
@@ -179,12 +170,29 @@ enum {
VD_AGENT_CLIPBOARD_IMAGE_JPG, /* optional */
};
+typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
+#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
+uint8_t selection;
+uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
+#endif
+#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
+string type;
+#else
+uint32_t type;
+#endif
+uint8_t data[0];
+} VDAgentClipboard;
+
typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
uint8_t selection;
uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
#endif
+#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
+string[] types;
+#else
uint32_t types[0];
+#endif
} VDAgentClipboardGrab;
typedef struct SPICE_ATTR_PACKED VDAgentClipboardRequest {
@@ -192,7 +200,11 @@ typedef struct SPICE_ATTR_PACKED VDAgentClipboardRequest
{
uint8_t selection;
uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
#endif
-uint32_t type;
+#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
+string type;
+#else
+uint32_t type; /* string type; */
+#endif
} VDAgentClipboardRequest;
typedef struct SPICE_ATTR_PACKED VDAgentClipboardRelease {
@@ -218,6 +230,7 @@ enum {
VD_AGENT_CAP_GUEST_LINEEND_LF,
VD_AGENT_CAP_GUEST_LINEEND_CRLF,
VD_AGENT_CAP_MAX_CLIPBOARD,
+VD_AGENT_CAP_ANY_SELECTION_TYPE,
VD_AGENT_END_CAP,
};
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 0/2] stability for dual head
On 06/03/2014 04:14 PM, David Mansfield wrote: Bump. I'll make it easy. This is a multiple choice response form. Anyone reading this can respond with one letter so save time and effort. a) We're too busy with RHEL 7/paying clients, come back in a month/some timeframe b) There's an SEP field on these problems, everyone who understands that code has moved on c) Go away d) Oops, I've been meaning to get back to you but I keep forgetting and life is hectic... e) Didn't you hear? SPICE is dead. f) Other. Please elaborate using the space provided below: The first patch looks good (just adjusting the #if to disable the print). I'll pick it up, thanks, you deserved a faster response. No idea what SEP is. On 05/27/2014 10:49 AM, David Mansfield wrote: On 05/19/2014 10:01 AM, David Mansfield wrote: This patch series addresses two critical bugs that prevent dual-head from working in a linux-linux environment. (All testing done on F20 fully updated as guest, host and client). We (myself and a colleague) have been using patched versions of qxl.ko and xorg-qxl for a week or so and these patches definitely solve the problems addressed by the invididual patches. Patches are against F20 package source. Please consider reviewing/accepting these patches without which dual head cannot be used(*) in linux. These patches or previous versions have been sent to the list but I have not received any feedback. (*) by coincidence, dual head with small-ish monitor sizes does work better on gnome3 than it does with other DE (ie. MATE or fluxbox) due simply to luck in the order that the monitors/surfaces ioctl are called, but not due to any design. I've opened/updated the freedesktop.org bugs with these two patches and some commentary. It would be helpful if the maintainers of the respective code bases (qxl.ko and xorg-qxl) could comment on these two patches or at least a resend in one month - we're really busy or something. Bugs: Multiple monitors broken in desktops other than gnome3 : https://bugs.freedesktop.org/show_bug.cgi?id=78131 xorg crashes due to assert() when a large image is created : https://bugs.freedesktop.org/show_bug.cgi?id=79317 ___ 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 spice-protocol] RFC: Add VD_AGENT_CAP_ANY_SELECTION_TYPE
On 06/09/2014 02:20 PM, Marc-André Lureau wrote:
- Original Message -
On 06/04/2014 07:45 PM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
When both the client and the agent advertize
VD_AGENT_CAP_ANY_SELECTION_TYPE capability, the existing
VDAgentClipboard messages are modified to embed string
representation of the selection mime type.
Handling arbitrary mime types allows to describe any selection data
type, instead of a limited fixed list. The approach to reuse the integer
representation to extend the type with a registry (like X's atoms) has
been discarded (too complicated without substential benefits)
A string is a \0 terminated utf8 byte array: foo\0
A string[] is a \0\0 terminated array of utf8 strings: foo\0bar\0\0.
So no null strings in the list? sounds fine to me (just need to verify
this in code).
Yes, empty string are invalid here (of course, shouldn't crash anyway)
And the client will need to handle window system specific changes? or
can it pass the mime types on without looking at them?
As long as the content is a MIME description-like, it can pass it.
(some application or window system may use invalid MIME, but I consider this
is not Spice to take care of, applications are flexible, they take what they
handle best)
And such behaviour will just be 'bug compatible' under spice - ACK by me.
---
spice/vd_agent.h | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/spice/vd_agent.h b/spice/vd_agent.h
index 7464661..2e24c87 100644
--- a/spice/vd_agent.h
+++ b/spice/vd_agent.h
@@ -161,15 +161,6 @@ enum {
VD_AGENT_ERROR,
};
-typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
-#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
-uint8_t selection;
-uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
-#endif
-uint32_t type;
-uint8_t data[0];
-} VDAgentClipboard;
-
enum {
VD_AGENT_CLIPBOARD_NONE = 0,
VD_AGENT_CLIPBOARD_UTF8_TEXT,
@@ -179,12 +170,29 @@ enum {
VD_AGENT_CLIPBOARD_IMAGE_JPG, /* optional */
};
+typedef struct SPICE_ATTR_PACKED VDAgentClipboard {
+#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
+uint8_t selection;
+uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
+#endif
+#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
+string type;
+#else
+uint32_t type;
+#endif
+uint8_t data[0];
+} VDAgentClipboard;
+
typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
uint8_t selection;
uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
#endif
+#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
+string[] types;
+#else
uint32_t types[0];
+#endif
} VDAgentClipboardGrab;
typedef struct SPICE_ATTR_PACKED VDAgentClipboardRequest {
@@ -192,7 +200,11 @@ typedef struct SPICE_ATTR_PACKED
VDAgentClipboardRequest {
uint8_t selection;
uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
#endif
-uint32_t type;
+#if 0 /* VD_AGENT_CAP_ANY_SELECTION_TYPE */
+string type;
+#else
+uint32_t type; /* string type; */
+#endif
} VDAgentClipboardRequest;
typedef struct SPICE_ATTR_PACKED VDAgentClipboardRelease {
@@ -218,6 +230,7 @@ enum {
VD_AGENT_CAP_GUEST_LINEEND_LF,
VD_AGENT_CAP_GUEST_LINEEND_CRLF,
VD_AGENT_CAP_MAX_CLIPBOARD,
+VD_AGENT_CAP_ANY_SELECTION_TYPE,
VD_AGENT_END_CAP,
};
___
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] qxl_kms: read virtual monitor size from xorg.conf
Signed-off-by: Alon Levy al...@redhat.com --- src/qxl_kms.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/qxl_kms.c b/src/qxl_kms.c index c31c62d..d952495 100644 --- a/src/qxl_kms.c +++ b/src/qxl_kms.c @@ -164,8 +164,8 @@ Bool qxl_pre_init_kms(ScrnInfoPtr pScrn, int flags) if (drmmode_pre_init(pScrn, qxl-drmmode, pScrn-bitsPerPixel / 8) == FALSE) goto out; -qxl-virtual_x = 1024; -qxl-virtual_y = 768; +qxl-virtual_x = -1; +qxl-virtual_y = -1; pScrn-display-virtualX = qxl-virtual_x; pScrn-display-virtualY = qxl-virtual_y; @@ -335,6 +335,9 @@ Bool qxl_screen_init_kms(SCREEN_INIT_ARGS_DECL) if (!xf86CrtcScreenInit (pScreen)) return FALSE; +qxl-virtual_x = pScrn-currentMode-HDisplay; +qxl-virtual_y = pScrn-currentMode-VDisplay; + if (!qxl_resize_primary_to_virtual (qxl)) return FALSE; -- 1.9.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] qxl_driver.c: fix compiler warning 'defined but not used' qxl_kernel_mode_enabled
Signed-off-by: Alon Levy al...@redhat.com
---
src/qxl_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qxl_driver.c b/src/qxl_driver.c
index b9aa0e9..d9bf447 100644
--- a/src/qxl_driver.c
+++ b/src/qxl_driver.c
@@ -1242,7 +1242,7 @@ qxl_init_scrn (ScrnInfoPtr pScrn, Bool kms)
pScrn-ValidMode= NULL;
}
-#ifdef XF86DRM_MODE
+#if defined(XF86DRM_MODE) !defined(XSPICE)
static char *
CreatePCIBusID(const struct pci_device *dev)
{
--
1.9.3
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 0/2] stability for dual head
On 06/09/2014 04:18 PM, David Mansfield wrote: On 06/09/2014 07:18 AM, Alon Levy wrote: On 06/03/2014 04:14 PM, David Mansfield wrote: Bump. I'll make it easy. This is a multiple choice response form. Anyone reading this can respond with one letter so save time and effort. a) We're too busy with RHEL 7/paying clients, come back in a month/some timeframe b) There's an SEP field on these problems, everyone who understands that code has moved on c) Go away d) Oops, I've been meaning to get back to you but I keep forgetting and life is hectic... e) Didn't you hear? SPICE is dead. f) Other. Please elaborate using the space provided below: The first patch looks good (just adjusting the #if to disable the print). I'll pick it up, thanks, you deserved a faster response. No idea what SEP is. Hi Alon, I followed Marc-André's advice and sent these out to DRI ond xorg mailing lists, respectively. The qxl.ko patch was picked up by Dave Airlie and committed to drm-next branch. The second is still without a home. (BTW: An SEP is a somebody else's problem effect, see http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem, popularized in Douglas Adams' Hitchhiker's Guide novel. Very funny concept.) Missed that. Any possibility of help with issue #2, the xorg-devel list is silent on this one and I don't know who the maintainer is specifically. Without this patch xorg-qxl is trivially crashable when using dual head at 1920x1200 resolution (or potentially lower resolution). 96 relocs with 512x512 chunks - what do you do to crash it? Soren Sandmann is the maintainer, but I did a release once, I can commit it once I'm done testing (need to allow large resolutions which by default are limited to surface0_area_size). ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] glz cleanup
Hi,
Hopefully this is not something someone discussed in the 193 unread
mails from spice-devel I have.
I'm trying to look more closely at the glz code, and it seems to be
split: decoder in glz, encoder in spice.
I propose to move them to spice-common. any objections?
The reason I propose and don't just send patches is that while moving
the server code was trivial moving the gtk code brings some baggage with
it: gio-coroutine and coroutine_{winfibers,gthread,ucontext} plus
spice_util (the later I may split to leave some gtk only util in
spice-gtk). Any objects to moving the coroutine stuff to spice-common?
Thanks,
Alon
p.s. g_debug related cleanups are also due (btw the whole split seems to
be because when spice-gtk was written spice still did not depend on
glib. it does now. spice-common doesn't but it is trivial to make it so,
and useful).
p.p.s. I don't think any of this has been done in the replay branch
(which we should merge..) so it shouldn't conflict much (just some
include changes - glz_bla.h - common/glz_bla.h)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 11/12] add benchmarks for memcpy (RtlCopyMemory) vs fast - fast is slower
On 05/02/2014 02:21 PM, Marc-André Lureau wrote:
- Original Message -
Two benchmarks:
1. standalone, actually uses LIBCMT's memcpy to compare.
2. Part of qxldd.dll (in display/res.c called from display/driver.c)
so using the same implementation.
Note: next commit removes benchmark code as well as fast_memcpy_* code
and related SSE check and FPU save/restore.
Why not keep it in a benchmark branch, instead of adding and removing?
works for me.
Results for 32 bit windows 7 give ~2 times better performance for
*system* memcpy.
64 bit windows 7 is ~2 times better for size 128 KByte copies, and
approximately the same for 128 KB = size = 1 MB
More complete results:
Note: for 64 bit with 262144 = size = 1048576 I got mixed results,
depending on the order of performing the comparison - if memcpy was run
first I got better results for fast_memcpy, by about 20%, for 64 bit
only (for 32 bit memcpy/RtlCopyMemory was still faster).
Windows 7 32 bit:
size [bytes] our time/system time [percent]
1024232
2048352
4096681
8192303
16384455
32768403
65536352
131072232
262144232
524288152
1048576177
Windows 7 64 bit:
size [bytes] our time/system time [percent]
1024140
2048204
4096200
8192198
16384232
32768173
65536272
131072177
262144134
524288115
1048576115
---
xddm/display/benchmark_memcpy.c| 152
+
xddm/display/driver.c | 4 +
xddm/display/res.c | 57 +
xddm/tests/benchmark_format_results.py | 38 +
xddm/tests/build_benchmark.bat | 7 ++
5 files changed, 258 insertions(+)
create mode 100644 xddm/display/benchmark_memcpy.c
create mode 100644 xddm/tests/benchmark_format_results.py
create mode 100644 xddm/tests/build_benchmark.bat
diff --git a/xddm/display/benchmark_memcpy.c
b/xddm/display/benchmark_memcpy.c
new file mode 100644
index 000..fa44577
--- /dev/null
+++ b/xddm/display/benchmark_memcpy.c
@@ -0,0 +1,152 @@
+#include windows.h
+#include stdio.h
+
+#ifdef _WIN64
+int have_sse2 = 0;
+void fast_memcpy_aligned(void *dest, const void *src, size_t len);
+#else
+static _inline void fast_memcpy_aligned(void *dest, const void *src, size_t
len)
+{
+_asm
+{
+mov ecx, len
+mov esi, src
+mov edi, dest
+
+cmp ecx, 128
+jb try_to_copy64
+
+prefetchnta [esi]
+copy_128:
+prefetchnta [esi + 64]
+
+movdqa xmm0, [esi]
+movdqa xmm1, [esi + 16]
+movdqa xmm2, [esi + 32]
+movdqa xmm3, [esi + 48]
+
+prefetchnta [esi + 128]
+
+movntdq [edi], xmm0
+movntdq [edi + 16], xmm1
+movntdq [edi + 32], xmm2
+movntdq [edi + 48], xmm3
+
+movdqa xmm0, [esi + 64]
+movdqa xmm1, [esi + 80]
+movdqa xmm2, [esi + 96]
+movdqa xmm3, [esi + 112]
+
+movntdq [edi + 64], xmm0
+movntdq [edi + 80], xmm1
+movntdq [edi + 96], xmm2
+movntdq [edi + 112], xmm3
+
+add edi, 128
+add esi, 128
+sub ecx, 128
+cmp ecx, 128
+jae copy_128
+
+ try_to_copy64:
+cmp ecx, 64
+jb try_to_copy32
+
+ movdqa xmm0, [esi]
+ movdqa xmm1, [esi + 16]
+ movdqa xmm2, [esi + 32]
+ movdqa xmm3, [esi + 48]
+
+ movntdq [edi], xmm0
+ movntdq [edi + 16], xmm1
+ movntdq [edi + 32], xmm2
+ movntdq [edi + 48], xmm3
+
+ add edi, 64
+ add esi, 64
+ sub ecx, 64
+ prefetchnta [esi]
+
+try_to_copy32:
+ cmp ecx, 32
+ jb try_to_copy16
+
+ movdqa xmm0, [esi]
+ movdqa xmm1, [esi + 16]
+ movntdq [edi], xmm0
+ movntdq [edi + 16], xmm1
+
+ add edi, 32
+ add esi, 32
+ sub ecx, 32
+
+try_to_copy16:
+ cmp ecx, 16
+ jb try_to_copy4
+
+ movdqa xmm0, [esi]
+ movntdq [edi], xmm0
+
+ add edi, 16
+ add esi, 16
+ sub ecx, 16
+
+
+try_to_copy4:
+cmp ecx, 4
+jb try_to_copy_1
+movsd
+sub ecx, 4
+jmp try_to_copy4
+
+try_to_copy_1:
+rep movsb
+
+sfence
+}
+}
+#endif
+
+typedef unsigned long long uint64_t;
+
+uint64_t
Re: [Spice-devel] [PATCH 01/12] Revert miniport: halve QXL_IO_UPDATE_IRQ calls
On 04/30/2014 07:28 PM, Marc-André Lureau wrote:
ack,
should the bug state be changed back to ASSIGNED?
I did that.
- Original Message -
From: Yonit Halperin yhalp...@redhat.com
This reverts commit 49feefa95d3595f04355c4aed53ec5bf26551046.
The patch causes the display to get stuck. Till we understand exactly
why, I'm reverting it.
---
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.9.0
___
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 05/12] build.bat: fix copy to install dir for amd64
On 04/30/2014 07:32 PM, Marc-André Lureau wrote: - Original Message - --- xddm/build.bat | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/xddm/build.bat b/xddm/build.bat index 1d19875..7dfe51b 100755 --- a/xddm/build.bat +++ b/xddm/build.bat @@ -16,6 +16,12 @@ if not DEFINED SPICE_COMMON_DIR ( set SPICE_COMMON_DIR=%CD%\..\spice-protocol ) +if defined AMD64 ( + set BUILD_ALT_DIR_SUBDIR=amd64 +) else ( + set BUILD_ALT_DIR_SUBDIR=i386 +) ARCH_DIR? that would make less confusion with the other variable BUILD_ALT_DIR This is on purpose, there is already a _BUILDARCH defined as x86/AMD64 as opposed to i386/amd64 (no environment variable provided by ddk batch 'setenv.bat' with this value), and we concatenate this value to BUILD_ALT_DIR, hence BUILD_ALT_DIR_SUBDIR. + set TARGET=install_%BUILD_ALT_DIR% echo TARGET=%TARGET% if not exist %TARGET% mkdir %TARGET% @@ -30,11 +36,11 @@ build -cZg cd ../ :copy_local -copy display\obj%BUILD_ALT_DIR%\i386\qxldd.dll %TARGET% -copy miniport\obj%BUILD_ALT_DIR%\i386\qxl.sys %TARGET% +copy display\obj%BUILD_ALT_DIR%\%BUILD_ALT_DIR_SUBDIR%\qxldd.dll %TARGET% +copy miniport\obj%BUILD_ALT_DIR%\%BUILD_ALT_DIR_SUBDIR%\qxl.sys %TARGET% copy miniport\qxl.inf %TARGET% -copy display\obj%BUILD_ALT_DIR%\i386\qxldd.pdb %TARGET% -copy miniport\obj%BUILD_ALT_DIR%\i386\qxl.pdb %TARGET% +copy display\obj%BUILD_ALT_DIR%\%BUILD_ALT_DIR_SUBDIR%\qxldd.pdb %TARGET% +copy miniport\obj%BUILD_ALT_DIR%\%BUILD_ALT_DIR_SUBDIR%\qxl.pdb %TARGET% if not defined DEST goto exit if exist %DEST% ( echo copying to %DEST% -- 1.9.0 ___ 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 02/12] miniport/qxl.inf: simplify by having FeatureScore for everyone
FeatureScore is the only difference between the _vista options and the rest, so just setting it also for windows xp using drivers results in a simplification of the inf file, and no downside. According to [1] we use a feature score of FC to indicate a windows 2000 display driver [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff569676%28v=vs.85%29.aspx --- xddm/miniport/qxl.inf | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/xddm/miniport/qxl.inf b/xddm/miniport/qxl.inf index dbd11dd..7144b7d 100644 --- a/xddm/miniport/qxl.inf +++ b/xddm/miniport/qxl.inf @@ -3,7 +3,7 @@ [Version] Signature = $CHICAGO$ -DriverVer = 07/17/2013,1.4.2.4 +DriverVer = 07/17/2013,1.4.2.4 Provider = %RHAT% CatalogFile = qxl.cat Class = Display @@ -17,30 +17,27 @@ qxl.Display = 11; system32 [Manufacturer] %RHAT% = q, NTx86, NTamd64, NTx86.6.0, NTamd64.6.0 -; WinXP x86 and up +; x86 [q.NTx86] %RHAT% %QXL% = qxl, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 -; WinXP x64 and up +; x64 [q.NTamd64] %RHAT% %QXL% = qxl, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 ; Vista x86 and up [q.NTx86.6.0] -%RHAT% %QXL% = qxl_vista, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 +%RHAT% %QXL% = qxl, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 ; Vista x64 and up [q.NTamd64.6.0] -%RHAT% %QXL% = qxl_vista, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 +%RHAT% %QXL% = qxl, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 [ControlFlags] ExcludeFromSelect = * [qxl] -CopyFiles = qxl.Miniport, qxl.Display - -[qxl_vista] FeatureScore = FC CopyFiles = qxl.Miniport, qxl.Display @@ -60,9 +57,6 @@ qxldd.dll = 1 [qxl.SoftwareSettings] AddReg = qxl_SoftwareDeviceSettings -[qxl_vista.SoftwareSettings] -AddReg = qxl_SoftwareDeviceSettings - [qxl_SoftwareDeviceSettings] HKR,, InstalledDisplayDrivers,%REG_MULTI_SZ%, qxldd HKR,, VgaCompatible, %REG_DWORD%,0 @@ -74,9 +68,6 @@ HKR,, Acceleration.Level, %REG_DWORD%,0 [qxl.Services] AddService = qxl, 0x0002, qxl_Service_Inst ; Assign the named service as the PnP function driver -[qxl_vista.Services] -AddService = qxl, 0x0002, qxl_Service_Inst ; Assign the named service as the PnP function driver - [qxl_Service_Inst] ServiceType= 1 ; SERVICE_KERNEL_DRIVER StartType = 3 ; SERVICE_DEMAND_START -- 1.9.0 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 05/12] build.bat: fix copy to install dir for amd64
--- xddm/build.bat | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/xddm/build.bat b/xddm/build.bat index 1d19875..7dfe51b 100755 --- a/xddm/build.bat +++ b/xddm/build.bat @@ -16,6 +16,12 @@ if not DEFINED SPICE_COMMON_DIR ( set SPICE_COMMON_DIR=%CD%\..\spice-protocol ) +if defined AMD64 ( + set BUILD_ALT_DIR_SUBDIR=amd64 +) else ( + set BUILD_ALT_DIR_SUBDIR=i386 +) + set TARGET=install_%BUILD_ALT_DIR% echo TARGET=%TARGET% if not exist %TARGET% mkdir %TARGET% @@ -30,11 +36,11 @@ build -cZg cd ../ :copy_local -copy display\obj%BUILD_ALT_DIR%\i386\qxldd.dll %TARGET% -copy miniport\obj%BUILD_ALT_DIR%\i386\qxl.sys %TARGET% +copy display\obj%BUILD_ALT_DIR%\%BUILD_ALT_DIR_SUBDIR%\qxldd.dll %TARGET% +copy miniport\obj%BUILD_ALT_DIR%\%BUILD_ALT_DIR_SUBDIR%\qxl.sys %TARGET% copy miniport\qxl.inf %TARGET% -copy display\obj%BUILD_ALT_DIR%\i386\qxldd.pdb %TARGET% -copy miniport\obj%BUILD_ALT_DIR%\i386\qxl.pdb %TARGET% +copy display\obj%BUILD_ALT_DIR%\%BUILD_ALT_DIR_SUBDIR%\qxldd.pdb %TARGET% +copy miniport\obj%BUILD_ALT_DIR%\%BUILD_ALT_DIR_SUBDIR%\qxl.pdb %TARGET% if not defined DEST goto exit if exist %DEST% ( echo copying to %DEST% -- 1.9.0 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 06/12] build.bat: more verbose build
--- xddm/build.bat | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/xddm/build.bat b/xddm/build.bat index 7dfe51b..b2c5149 100755 --- a/xddm/build.bat +++ b/xddm/build.bat @@ -30,9 +30,10 @@ if not x%1 == x set DEST=%1 :build cd miniport -build -cZg +build -ceZg cd ../display -build -cZg +build -ceZg +type buildchk_win7_%_BUILDARCH%.log | find warning cd ../ :copy_local -- 1.9.0 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 08/12] adding initial empty AMD64 only external asm file
--- xddm/display/amd64/x64.asm | 1 + xddm/display/sources | 1 + 2 files changed, 2 insertions(+) create mode 100644 xddm/display/amd64/x64.asm diff --git a/xddm/display/amd64/x64.asm b/xddm/display/amd64/x64.asm new file mode 100644 index 000..e32b0df --- /dev/null +++ b/xddm/display/amd64/x64.asm @@ -0,0 +1 @@ +end \ No newline at end of file diff --git a/xddm/display/sources b/xddm/display/sources index 6c1d5c7..8a4f664 100644 --- a/xddm/display/sources +++ b/xddm/display/sources @@ -32,3 +32,4 @@ SOURCES=driver.c\ surface.c \ driver.rc +AMD64_SOURCES=amd64\x64.asm -- 1.9.0 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 03/12] display/res.h: remove whitespace at EOF
--- xddm/display/res.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xddm/display/res.h b/xddm/display/res.h index 6ce9a68..4d179c5 100644 --- a/xddm/display/res.h +++ b/xddm/display/res.h @@ -74,4 +74,4 @@ void EmptyReleaseRing(PDev *pdev); void InitDeviceMemoryResources(PDev *pdev); void ReleaseCacheDeviceMemoryResources(PDev *pdev); -#endif +#endif \ No newline at end of file -- 1.9.0 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 04/12] display\driver.c: remove unused FlotaToFixed
---
xddm/display/driver.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/xddm/display/driver.c b/xddm/display/driver.c
index aa4fe42..5a3dbfa 100644
--- a/xddm/display/driver.c
+++ b/xddm/display/driver.c
@@ -1252,20 +1252,6 @@ char *BitmapTypeToStr(int type)
#include utils.h
#include res.h
-FIX FlotaToFixed(FLOATL val, FLOATL scale)
-{
-FLOATOBJ float_obj;
-FIX ret;
-
-FLOATOBJ_SetFloat(float_obj, val);
-FLOATOBJ_MulFloat(float_obj, scale);
-
-ret = FLOATOBJ_GetLong(float_obj) 4;
-FLOATOBJ_MulLong(float_obj, 16);
-ret |= (0x0f FLOATOBJ_GetLong(float_obj));
-return ret;
-}
-
static BOOL GetCosmeticAttr(PDev *pdev, QXLDrawable *drawable, QXLLineAttr
*q_line_attr,
LINEATTRS *line_attr)
{
--
1.9.0
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 01/12] Revert miniport: halve QXL_IO_UPDATE_IRQ calls
From: Yonit Halperin yhalp...@redhat.com
This reverts commit 49feefa95d3595f04355c4aed53ec5bf26551046.
The patch causes the display to get stuck. Till we understand exactly
why, I'm reverting it.
---
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.9.0
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 07/12] xddm/display/res.c: move ALIGN out of Save/RestoreFPU for easier amd64 implementation
---
xddm/display/res.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/xddm/display/res.c b/xddm/display/res.c
index bfb3571..289ece5 100644
--- a/xddm/display/res.c
+++ b/xddm/display/res.c
@@ -1811,13 +1811,11 @@ static void FreeBitmapImage(PDev *pdev, Resource *res)
// todo: defer
#ifndef _WIN64
-static _inline void RestoreFPU(PDev *pdev, UINT8 FPUSave[])
+static _inline void RestoreFPU(PDev *pdev, size_t aligned_addr)
{
-void *align_addr = (void *)ALIGN((size_t)(FPUSave), SSE_ALIGN);
-
_asm
{
-mov esi, align_addr
+mov esi, aligned_addr
movdqa xmm0, [esi]
movdqa xmm1, [esi + 16]
@@ -1826,13 +1824,11 @@ static _inline void RestoreFPU(PDev *pdev, UINT8
FPUSave[])
}
}
-static _inline void SaveFPU(PDev *pdev, UINT8 FPUSave[])
+static _inline void SaveFPU(PDev *pdev, size_t aligned_addr)
{
-void *align_addr = (void *)ALIGN((size_t)(FPUSave), SSE_ALIGN);
-
_asm
{
-mov edi, align_addr
+mov edi, aligned_addr
movdqa [edi], xmm0
movdqa [edi + 16], xmm1
@@ -1865,7 +1861,8 @@ static _inline Resource *GetBitmapImage(PDev *pdev,
SURFOBJ *surf, XLATEOBJ *col
UINT8 *src_end;
UINT8 *dest;
UINT8 *dest_end;
-UINT8 FPUSave[16 * 4 + 15];
+UINT8 FPUSaveUnaligned[16 * 4 + 15];
+size_t FPUSave = ALIGN((size_t)(FPUSaveUnaligned), SSE_ALIGN);
BOOL use_sse = FALSE;
DEBUG_PRINT((pdev, 12, %s\n, __FUNCTION__));
--
1.9.0
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 00/12] Fix 705785 (remove fast_memcpy_*)
This patchset ultimately does a little cleanup and mainly removes all inline assembly that was used to supposedly have a faster memcpy implementation. The patchset includes an amd64 implementation of the fast_memcpy_aligned and fast_memcpy_unaligned functions and benchmarks comparing them to RtlCopyMemory and memcpy (the later for easier testing in userspace, but the comparison was ultimately done in kernel since I couldn't find a simple way to link to the kernel memcpy implementation from userspace). Both benchmarks and amd64 (and original x86) implementations are removed in the final patch. Benchmarks show that on the tested systems (windows 7 32 64 bits with emulated host cpu i7) the native windows kernel implementation was faster. For more information see commit message of benchmark adding commit (one before last). In addition the patch to revert an earlier mistake miniport: halve QXL_IO_UPDATE_IRQ calls is included. Alon Levy (11): miniport/qxl.inf: simplify by having FeatureScore for everyone display/res.h: remove whitespace at EOF display\driver.c: remove unused FlotaToFixed build.bat: fix copy to install dir for amd64 build.bat: more verbose build xddm/display/res.c: move ALIGN out of Save/RestoreFPU for easier amd64 implementation adding initial empty AMD64 only external asm file xddm/display/amd64: implement CheckAndSetSSE2 xddm/display/amd64: implement Save/RestoreFPU fast_memcpy_* add benchmarks for memcpy (RtlCopyMemory) vs fast - fast is slower display: use RtlCopyMemory instead of fast_memcpy_* Yonit Halperin (1): Revert miniport: halve QXL_IO_UPDATE_IRQ calls xddm/build.bat | 19 ++- xddm/display/benchmark_memcpy.c | 152 ++ xddm/display/driver.c | 17 -- xddm/display/res.c | 335 ++-- xddm/display/res.h | 5 +- xddm/display/sources| 3 +- xddm/miniport/qxl.c | 1 + xddm/miniport/qxl.inf | 19 +-- 8 files changed, 188 insertions(+), 363 deletions(-) mode change 100755 = 100644 xddm/build.bat create mode 100644 xddm/display/benchmark_memcpy.c -- 1.9.0 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 12/12] display: use RtlCopyMemory instead of fast_memcpy_*
It is common practice to use RtlCopyMemory. Currently it is defined by the preprocessor to be memcpy, which outperforms our implementation, see previous benchmark commit. This commit removes the benchmarks and our internal implementation in favor of RtlCopyMemory. RHBZ: 705785 --- xddm/build.bat | 0 xddm/display/amd64/x64.asm | 250 - xddm/display/driver.c | 7 - xddm/display/res.c | 392 ++--- xddm/display/res.h | 3 - xddm/display/sources | 4 +- xddm/tests/benchmark_format_results.py | 38 xddm/tests/build_benchmark.bat | 7 - 8 files changed, 17 insertions(+), 684 deletions(-) mode change 100755 = 100644 xddm/build.bat delete mode 100644 xddm/display/amd64/x64.asm delete mode 100644 xddm/tests/benchmark_format_results.py delete mode 100644 xddm/tests/build_benchmark.bat diff --git a/xddm/build.bat b/xddm/build.bat old mode 100755 new mode 100644 diff --git a/xddm/display/amd64/x64.asm b/xddm/display/amd64/x64.asm deleted file mode 100644 index bb45d33..000 --- a/xddm/display/amd64/x64.asm +++ /dev/null @@ -1,250 +0,0 @@ -Extern have_sse2:DWORD - -.code - -CheckAndSetSSE2 proc -mov eax, 001h -cpuid -and edx, 400h -shr edx, 26 -mov have_sse2, edx -ret -CheckAndSetSSE2 endp - -RestoreFPU proc -; rcx PDev *pdev -; rdx size_t aligned_addr -movdqa xmm0, [rcx] -movdqa xmm1, [rcx + 16] -movdqa xmm2, [rcx + 32] -movdqa xmm3, [rcx + 48] -ret -RestoreFPU endp - -SaveFPU proc -; rcx PDev *pdev -; rdx size_t aligned_addr -movdqa [rcx], xmm0 -movdqa [rcx + 16], xmm1 -movdqa [rcx + 32], xmm2 -movdqa [rcx + 48], xmm3 -ret -SaveFPU endp - -fast_memcpy_aligned proc -; rcx void *dest -; rdx const void *src -; r8 size_t len -; Save rsi and rdi -mov r9, rsi -mov r10, rdi - -mov rsi, rdx -mov rdi, rcx -mov rcx, r8 - -cmp rcx, 128 -jb try_to_copy64 - -prefetchnta [rsi] -copy_128: -prefetchnta [rsi + 64] - -movdqa xmm0, [rsi] -movdqa xmm1, [rsi + 16] -movdqa xmm2, [rsi + 32] -movdqa xmm3, [rsi + 48] - -prefetchnta [rsi + 128] - -movntdq [rdi], xmm0 -movntdq [rdi + 16], xmm1 -movntdq [rdi + 32], xmm2 -movntdq [rdi + 48], xmm3 - -movdqa xmm0, [rsi + 64] -movdqa xmm1, [rsi + 80] -movdqa xmm2, [rsi + 96] -movdqa xmm3, [rsi + 112] - -movntdq [rdi + 64], xmm0 -movntdq [rdi + 80], xmm1 -movntdq [rdi + 96], xmm2 -movntdq [rdi + 112], xmm3 - -add rdi, 128 -add rsi, 128 -sub rcx, 128 -cmp rcx, 128 -jae copy_128 - - try_to_copy64: -cmp rcx, 64 -jb try_to_copy32 - - movdqa xmm0, [rsi] - movdqa xmm1, [rsi + 16] - movdqa xmm2, [rsi + 32] - movdqa xmm3, [rsi + 48] - - movntdq [rdi], xmm0 - movntdq [rdi + 16], xmm1 - movntdq [rdi + 32], xmm2 - movntdq [rdi + 48], xmm3 - - add rdi, 64 - add rsi, 64 - sub rcx, 64 - prefetchnta [rsi] - -try_to_copy32: - cmp rcx, 32 - jb try_to_copy16 - - movdqa xmm0, [rsi] - movdqa xmm1, [rsi + 16] - movntdq [rdi], xmm0 - movntdq [rdi + 16], xmm1 - - add rdi, 32 - add rsi, 32 - sub rcx, 32 - -try_to_copy16: - cmp rcx, 16 - jb try_to_copy4 - - movdqa xmm0, [rsi] - movntdq [rdi], xmm0 - - add rdi, 16 - add rsi, 16 - sub rcx, 16 - - -try_to_copy4: -cmp rcx, 4 -jb try_to_copy_1 -movsd -sub rcx, 4 -jmp try_to_copy4 - -try_to_copy_1: -rep movsb - -sfence -; Save rsi and rdi -mov rsi, r9 -mov rdi, r10 -ret -fast_memcpy_aligned endp - -fast_memcpy_unaligned proc -; rcx void *dest -; rdx const void *src -; r8 size_t len -; Save rsi and rdi -mov r9, rsi -mov r10, rdi - -mov rsi, rdx -mov rdi, rcx -mov rcx, r8 - -cmp rcx, 128 -jb try_to_copy64 - -prefetchnta [rsi] -copy_128: -prefetchnta [rsi + 64] - -movdqu xmm0, [rsi] -movdqu xmm1, [rsi + 16] -movdqu xmm2, [rsi + 32] -movdqu xmm3, [rsi + 48] - -prefetchnta [rsi + 128] - -movntdq [rdi], xmm0 -movntdq [rdi + 16], xmm1 -movntdq [rdi + 32], xmm2 -movntdq [rdi + 48], xmm3 - -movdqu xmm0, [rsi + 64] -movdqu xmm1, [rsi + 80] -movdqu xmm2, [rsi + 96] -movdqu xmm3, [rsi + 112] - -movntdq [rdi + 64], xmm0 -movntdq [rdi + 80], xmm1 -movntdq [rdi + 96], xmm2 -movntdq [rdi + 112], xmm3 - -add rdi, 128 -add rsi, 128 -sub rcx, 128 -cmp rcx, 128 -jae copy_128 - -
[Spice-devel] [PATCH 09/12] xddm/display/amd64: implement CheckAndSetSSE2
---
xddm/display/amd64/x64.asm | 13 +
xddm/display/res.c | 4
2 files changed, 17 insertions(+)
diff --git a/xddm/display/amd64/x64.asm b/xddm/display/amd64/x64.asm
index e32b0df..36971d3 100644
--- a/xddm/display/amd64/x64.asm
+++ b/xddm/display/amd64/x64.asm
@@ -1 +1,14 @@
+Extern have_sse2:DWORD
+
+.code
+
+CheckAndSetSSE2 proc
+mov eax, 001h
+cpuid
+and edx, 400h
+shr edx, 26
+mov have_sse2, edx
+ret
+CheckAndSetSSE2 endp
+
end
\ No newline at end of file
diff --git a/xddm/display/res.c b/xddm/display/res.c
index 289ece5..9320dd1 100644
--- a/xddm/display/res.c
+++ b/xddm/display/res.c
@@ -124,7 +124,11 @@ typedef struct QXLOutput {
UINT8 data[0];
} QXLOutput;
+#ifndef _WIN64
static int have_sse2 = FALSE;
+#else
+int have_sse2 = FALSE;
+#endif
#ifndef DBG
static _inline void DebugShowOutput(PDev *pdev, QXLOutput* output)
--
1.9.0
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH 11/12] add benchmarks for memcpy (RtlCopyMemory) vs fast - fast is slower
Two benchmarks:
1. standalone, actually uses LIBCMT's memcpy to compare.
2. Part of qxldd.dll (in display/res.c called from display/driver.c)
so using the same implementation.
Note: next commit removes benchmark code as well as fast_memcpy_* code
and related SSE check and FPU save/restore.
Results for 32 bit windows 7 give ~2 times better performance for
*system* memcpy.
64 bit windows 7 is ~2 times better for size 128 KByte copies, and
approximately the same for 128 KB = size = 1 MB
More complete results:
Note: for 64 bit with 262144 = size = 1048576 I got mixed results,
depending on the order of performing the comparison - if memcpy was run
first I got better results for fast_memcpy, by about 20%, for 64 bit
only (for 32 bit memcpy/RtlCopyMemory was still faster).
Windows 7 32 bit:
size [bytes] our time/system time [percent]
1024232
2048352
4096681
8192303
16384455
32768403
65536352
131072232
262144232
524288152
1048576177
Windows 7 64 bit:
size [bytes] our time/system time [percent]
1024140
2048204
4096200
8192198
16384232
32768173
65536272
131072177
262144134
524288115
1048576115
---
xddm/display/benchmark_memcpy.c| 152 +
xddm/display/driver.c | 4 +
xddm/display/res.c | 57 +
xddm/tests/benchmark_format_results.py | 38 +
xddm/tests/build_benchmark.bat | 7 ++
5 files changed, 258 insertions(+)
create mode 100644 xddm/display/benchmark_memcpy.c
create mode 100644 xddm/tests/benchmark_format_results.py
create mode 100644 xddm/tests/build_benchmark.bat
diff --git a/xddm/display/benchmark_memcpy.c b/xddm/display/benchmark_memcpy.c
new file mode 100644
index 000..fa44577
--- /dev/null
+++ b/xddm/display/benchmark_memcpy.c
@@ -0,0 +1,152 @@
+#include windows.h
+#include stdio.h
+
+#ifdef _WIN64
+int have_sse2 = 0;
+void fast_memcpy_aligned(void *dest, const void *src, size_t len);
+#else
+static _inline void fast_memcpy_aligned(void *dest, const void *src, size_t
len)
+{
+_asm
+{
+mov ecx, len
+mov esi, src
+mov edi, dest
+
+cmp ecx, 128
+jb try_to_copy64
+
+prefetchnta [esi]
+copy_128:
+prefetchnta [esi + 64]
+
+movdqa xmm0, [esi]
+movdqa xmm1, [esi + 16]
+movdqa xmm2, [esi + 32]
+movdqa xmm3, [esi + 48]
+
+prefetchnta [esi + 128]
+
+movntdq [edi], xmm0
+movntdq [edi + 16], xmm1
+movntdq [edi + 32], xmm2
+movntdq [edi + 48], xmm3
+
+movdqa xmm0, [esi + 64]
+movdqa xmm1, [esi + 80]
+movdqa xmm2, [esi + 96]
+movdqa xmm3, [esi + 112]
+
+movntdq [edi + 64], xmm0
+movntdq [edi + 80], xmm1
+movntdq [edi + 96], xmm2
+movntdq [edi + 112], xmm3
+
+add edi, 128
+add esi, 128
+sub ecx, 128
+cmp ecx, 128
+jae copy_128
+
+ try_to_copy64:
+cmp ecx, 64
+jb try_to_copy32
+
+ movdqa xmm0, [esi]
+ movdqa xmm1, [esi + 16]
+ movdqa xmm2, [esi + 32]
+ movdqa xmm3, [esi + 48]
+
+ movntdq [edi], xmm0
+ movntdq [edi + 16], xmm1
+ movntdq [edi + 32], xmm2
+ movntdq [edi + 48], xmm3
+
+ add edi, 64
+ add esi, 64
+ sub ecx, 64
+ prefetchnta [esi]
+
+try_to_copy32:
+ cmp ecx, 32
+ jb try_to_copy16
+
+ movdqa xmm0, [esi]
+ movdqa xmm1, [esi + 16]
+ movntdq [edi], xmm0
+ movntdq [edi + 16], xmm1
+
+ add edi, 32
+ add esi, 32
+ sub ecx, 32
+
+try_to_copy16:
+ cmp ecx, 16
+ jb try_to_copy4
+
+ movdqa xmm0, [esi]
+ movntdq [edi], xmm0
+
+ add edi, 16
+ add esi, 16
+ sub ecx, 16
+
+
+try_to_copy4:
+cmp ecx, 4
+jb try_to_copy_1
+movsd
+sub ecx, 4
+jmp try_to_copy4
+
+try_to_copy_1:
+rep movsb
+
+sfence
+}
+}
+#endif
+
+typedef unsigned long long uint64_t;
+
+uint64_t time_usecs(void)
+{
+ SYSTEMTIME systime;
+ GetSystemTime(systime);
+ return systime.wMilliseconds * 1000 + systime.wSecond * 1e6 +
systime.wMinute * 60e6 + systime.wHour * 3600e6;
+}
+
+int main(void)
+{
+ int i;
+ unsigned char *src_unaligned;
+ unsigned char *dest_unaligned;
+ uint64_t start, total1, total2;
+ unsigned char *src = NULL;
+
[Spice-devel] [PATCH 10/12] xddm/display/amd64: implement Save/RestoreFPU fast_memcpy_*
Some notes: Follows AMD64 calling conventions. Uses masm 64 (ml64.exe). Dropped in the next patches because it is too slow. --- xddm/display/amd64/x64.asm | 236 + xddm/display/res.c | 13 +-- 2 files changed, 241 insertions(+), 8 deletions(-) diff --git a/xddm/display/amd64/x64.asm b/xddm/display/amd64/x64.asm index 36971d3..bb45d33 100644 --- a/xddm/display/amd64/x64.asm +++ b/xddm/display/amd64/x64.asm @@ -11,4 +11,240 @@ CheckAndSetSSE2 proc ret CheckAndSetSSE2 endp +RestoreFPU proc +; rcx PDev *pdev +; rdx size_t aligned_addr +movdqa xmm0, [rcx] +movdqa xmm1, [rcx + 16] +movdqa xmm2, [rcx + 32] +movdqa xmm3, [rcx + 48] +ret +RestoreFPU endp + +SaveFPU proc +; rcx PDev *pdev +; rdx size_t aligned_addr +movdqa [rcx], xmm0 +movdqa [rcx + 16], xmm1 +movdqa [rcx + 32], xmm2 +movdqa [rcx + 48], xmm3 +ret +SaveFPU endp + +fast_memcpy_aligned proc +; rcx void *dest +; rdx const void *src +; r8 size_t len +; Save rsi and rdi +mov r9, rsi +mov r10, rdi + +mov rsi, rdx +mov rdi, rcx +mov rcx, r8 + +cmp rcx, 128 +jb try_to_copy64 + +prefetchnta [rsi] +copy_128: +prefetchnta [rsi + 64] + +movdqa xmm0, [rsi] +movdqa xmm1, [rsi + 16] +movdqa xmm2, [rsi + 32] +movdqa xmm3, [rsi + 48] + +prefetchnta [rsi + 128] + +movntdq [rdi], xmm0 +movntdq [rdi + 16], xmm1 +movntdq [rdi + 32], xmm2 +movntdq [rdi + 48], xmm3 + +movdqa xmm0, [rsi + 64] +movdqa xmm1, [rsi + 80] +movdqa xmm2, [rsi + 96] +movdqa xmm3, [rsi + 112] + +movntdq [rdi + 64], xmm0 +movntdq [rdi + 80], xmm1 +movntdq [rdi + 96], xmm2 +movntdq [rdi + 112], xmm3 + +add rdi, 128 +add rsi, 128 +sub rcx, 128 +cmp rcx, 128 +jae copy_128 + + try_to_copy64: +cmp rcx, 64 +jb try_to_copy32 + + movdqa xmm0, [rsi] + movdqa xmm1, [rsi + 16] + movdqa xmm2, [rsi + 32] + movdqa xmm3, [rsi + 48] + + movntdq [rdi], xmm0 + movntdq [rdi + 16], xmm1 + movntdq [rdi + 32], xmm2 + movntdq [rdi + 48], xmm3 + + add rdi, 64 + add rsi, 64 + sub rcx, 64 + prefetchnta [rsi] + +try_to_copy32: + cmp rcx, 32 + jb try_to_copy16 + + movdqa xmm0, [rsi] + movdqa xmm1, [rsi + 16] + movntdq [rdi], xmm0 + movntdq [rdi + 16], xmm1 + + add rdi, 32 + add rsi, 32 + sub rcx, 32 + +try_to_copy16: + cmp rcx, 16 + jb try_to_copy4 + + movdqa xmm0, [rsi] + movntdq [rdi], xmm0 + + add rdi, 16 + add rsi, 16 + sub rcx, 16 + + +try_to_copy4: +cmp rcx, 4 +jb try_to_copy_1 +movsd +sub rcx, 4 +jmp try_to_copy4 + +try_to_copy_1: +rep movsb + +sfence +; Save rsi and rdi +mov rsi, r9 +mov rdi, r10 +ret +fast_memcpy_aligned endp + +fast_memcpy_unaligned proc +; rcx void *dest +; rdx const void *src +; r8 size_t len +; Save rsi and rdi +mov r9, rsi +mov r10, rdi + +mov rsi, rdx +mov rdi, rcx +mov rcx, r8 + +cmp rcx, 128 +jb try_to_copy64 + +prefetchnta [rsi] +copy_128: +prefetchnta [rsi + 64] + +movdqu xmm0, [rsi] +movdqu xmm1, [rsi + 16] +movdqu xmm2, [rsi + 32] +movdqu xmm3, [rsi + 48] + +prefetchnta [rsi + 128] + +movntdq [rdi], xmm0 +movntdq [rdi + 16], xmm1 +movntdq [rdi + 32], xmm2 +movntdq [rdi + 48], xmm3 + +movdqu xmm0, [rsi + 64] +movdqu xmm1, [rsi + 80] +movdqu xmm2, [rsi + 96] +movdqu xmm3, [rsi + 112] + +movntdq [rdi + 64], xmm0 +movntdq [rdi + 80], xmm1 +movntdq [rdi + 96], xmm2 +movntdq [rdi + 112], xmm3 + +add rdi, 128 +add rsi, 128 +sub rcx, 128 +cmp rcx, 128 +jae copy_128 + + try_to_copy64: +cmp rcx, 64 +jb try_to_copy32 + + movdqu xmm0, [rsi] + movdqu xmm1, [rsi + 16] + movdqu xmm2, [rsi + 32] + movdqu xmm3, [rsi + 48] + + movntdq [rdi], xmm0 + movntdq [rdi + 16], xmm1 + movntdq [rdi + 32], xmm2 + movntdq [rdi + 48], xmm3 + + add rdi, 64 + add rsi, 64 + sub rcx, 64 + prefetchnta [rsi] + +try_to_copy32: + cmp rcx, 32 + jb try_to_copy16 + + movdqu xmm0, [rsi] + movdqu xmm1, [rsi + 16] + movntdq [rdi], xmm0 + movntdq [rdi + 16], xmm1 + + add rdi, 32 + add rsi, 32 + sub rcx, 32 + +try_to_copy16: + cmp rcx, 16 + jb try_to_copy4 + + movdqu xmm0, [rsi] + movntdq [rdi], xmm0 + + add rdi, 16 + add rsi, 16 +
Re: [Spice-devel] [PATCH 02/12] miniport/qxl.inf: simplify by having FeatureScore for everyone
I forgot to mention in the cover letter: I fixed the comment here per old review by Yonit. Review appreciated! On 04/30/2014 05:40 PM, Alon Levy wrote: FeatureScore is the only difference between the _vista options and the rest, so just setting it also for windows xp using drivers results in a simplification of the inf file, and no downside. According to [1] we use a feature score of FC to indicate a windows 2000 display driver [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff569676%28v=vs.85%29.aspx --- xddm/miniport/qxl.inf | 19 +-- 1 file changed, 5 insertions(+), 14 deletions(-) diff --git a/xddm/miniport/qxl.inf b/xddm/miniport/qxl.inf index dbd11dd..7144b7d 100644 --- a/xddm/miniport/qxl.inf +++ b/xddm/miniport/qxl.inf @@ -3,7 +3,7 @@ [Version] Signature = $CHICAGO$ -DriverVer = 07/17/2013,1.4.2.4 +DriverVer = 07/17/2013,1.4.2.4 Provider = %RHAT% CatalogFile = qxl.cat Class = Display @@ -17,30 +17,27 @@ qxl.Display = 11 ; system32 [Manufacturer] %RHAT% = q, NTx86, NTamd64, NTx86.6.0, NTamd64.6.0 -; WinXP x86 and up +; x86 [q.NTx86] %RHAT% %QXL% = qxl, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 -; WinXP x64 and up +; x64 [q.NTamd64] %RHAT% %QXL% = qxl, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 ; Vista x86 and up [q.NTx86.6.0] -%RHAT% %QXL% = qxl_vista, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 +%RHAT% %QXL% = qxl, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 ; Vista x64 and up [q.NTamd64.6.0] -%RHAT% %QXL% = qxl_vista, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 +%RHAT% %QXL% = qxl, PCI\VEN_1b36DEV_0100SUBSYS_11001af4 [ControlFlags] ExcludeFromSelect = * [qxl] -CopyFiles = qxl.Miniport, qxl.Display - -[qxl_vista] FeatureScore = FC CopyFiles = qxl.Miniport, qxl.Display @@ -60,9 +57,6 @@ qxldd.dll = 1 [qxl.SoftwareSettings] AddReg = qxl_SoftwareDeviceSettings -[qxl_vista.SoftwareSettings] -AddReg = qxl_SoftwareDeviceSettings - [qxl_SoftwareDeviceSettings] HKR,, InstalledDisplayDrivers,%REG_MULTI_SZ%, qxldd HKR,, VgaCompatible, %REG_DWORD%,0 @@ -74,9 +68,6 @@ HKR,, Acceleration.Level, %REG_DWORD%,0 [qxl.Services] AddService = qxl, 0x0002, qxl_Service_Inst ; Assign the named service as the PnP function driver -[qxl_vista.Services] -AddService = qxl, 0x0002, qxl_Service_Inst ; Assign the named service as the PnP function driver - [qxl_Service_Inst] ServiceType= 1 ; SERVICE_KERNEL_DRIVER StartType = 3 ; SERVICE_DEMAND_START ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 3/2] marshaller: Use #include for headers in $srcdir/common
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/2014 12:27 PM, Christophe Fergeau wrote:
Ping ?
If this doesn't break (i.e. we have a -I directive for every required
directory) then ack.
On Tue, Mar 25, 2014 at 04:40:14PM +0100, Christophe Fergeau
wrote:
Since the (de)marshallers are now generated in $builddir and not
in $srcdir, when these generated files include a file located in
$srcdir/common, the compiler will find them thanks to a -I
directive, so it makes more sense to use rather than when
including them. --- Hey,
I finally got what you meant in this review comment, and this
should be addessed by this additional patch
Christophe
python_modules/demarshal.py | 2 +- spice_codegen.py|
4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/python_modules/demarshal.py
b/python_modules/demarshal.py index 794cd25..b7e51dc 100644 ---
a/python_modules/demarshal.py +++ b/python_modules/demarshal.py
@@ -1250,7 +1250,7 @@ def write_includes(writer):
writer.writeln(#include stdio.h) writer.writeln(#include
spice/protocol.h) writer.writeln(#include spice/macros.h)
-writer.writeln('#include common/mem.h') +
writer.writeln('#include common/mem.h') writer.newline()
writer.writeln(#ifdef _MSC_VER) writer.writeln(#pragma
warning(disable:4101)) diff --git a/spice_codegen.py
b/spice_codegen.py index d35d949..c8376cc 100755 ---
a/spice_codegen.py +++ b/spice_codegen.py @@ -209,8 +209,8 @@ if
options.print_error:
if options.includes: for i in options.includes: -
writer.header.writeln('#include %s' % i) -
writer.writeln('#include %s' % i) +
writer.header.writeln('#include %s' % i) +
writer.writeln('#include %s' % i)
if options.generate_enums or options.generate_dissector:
write_enums(writer, options.generate_dissector) -- 1.8.5.3
___ 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTQYk2AAoJEGSFt2Lm6PXuTvIH/Rl6cDrPGzt2qIml4OXDPCAe
HKaZKwK0iIcdEKF+E/6y8pvSLLsysj0aLbs0KwmkHjOGBgVXJmWJhK/+ADtq7pUb
ZMgS18Pb91QEcmqJm6v5kOGWjt3LIQx6quK9EpOu273vbyoqEG9zk/zZhprm7phJ
snIsrn9x9bB2ARTHOjgN4a6M+HAlVoMSXZRpE/UC4x0qyTNqXjZaJUpzzKKbAnKC
9M+nSPl4sIa3OFdHyrBQXmfYuJ08kH4r+gfBXD5Mbz1HgVIoie/em+Gf+Fktb6oO
I+J+9frDohVg/AcRxtmXHJpGOmrAEv7miTyGsf+Od4emxHYFtn9NGprAmCfnAvE=
=i/3d
-END PGP SIGNATURE-
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk 1/2] Add webdav channel
On 03/19/2014 07:33 PM, Marc-André Lureau wrote:
Hi
On Mon, Mar 17, 2014 at 8:54 AM, Alon Levy al...@redhat.com wrote:
Would be nice to use an actual constant for this instead of relying on
G_MAXUINT16 here and above.
Sorry, I forgot to address your comments.
What about MAX_MUX_SIZE?
ACK.
Rest of the diff would be:
diff --git a/gtk/channel-webdav.c b/gtk/channel-webdav.c
index ffd617e..2cc242b 100644
--- a/gtk/channel-webdav.c
+++ b/gtk/channel-webdav.c
@@ -79,7 +79,7 @@ typedef struct _OutputQueueElem {
OutputQueue *queue;
const guint8 *buf;
gsize size;
-GFunc cb;
+GFunc pushed_cb;
gpointer user_data;
} OutputQueueElem;
@@ -97,7 +97,6 @@ static void output_queue_free(OutputQueue *queue)
{
g_warn_if_fail(g_queue_get_length(queue-queue) == 0);
g_warn_if_fail(!queue-flushing);
-g_warn_if_fail(!queue-idle_id);
g_queue_free_full(queue-queue, g_free);
g_clear_object(queue-output);
@@ -150,8 +149,8 @@ static gboolean output_queue_idle(gpointer user_data)
g_output_stream_write_all(q-output, e-buf, e-size, NULL, NULL,
error);
if (error)
goto err;
-else if (e-cb)
-e-cb(q, e-user_data);
+else if (e-pushed_cb)
+e-pushed_cb(q, e-user_data);
q-flushing = TRUE;
g_output_stream_flush_async(q-output, G_PRIORITY_DEFAULT, NULL,
output_queue_flush_cb, e);
@@ -173,7 +172,7 @@ static void output_queue_push(OutputQueue *q, const
guint8 *buf, gsize size,
e-buf = buf;
e-size = size;
-e-cb = pushed_cb;
+e-pushed_cb = pushed_cb;
e-user_data = user_data;
e-queue = q;
g_queue_push_tail(q-queue, e);
@@ -248,6 +247,8 @@ static void mux_pushed_cb(OutputQueue *q, gpointer
user_data)
client_unref(client);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk 1/2] Add webdav channel
On 02/28/2014 02:16 PM, Marc-André Lureau wrote:
From: Marc-André Lureau marcandre.lur...@redhat.com
See spice-common for protocol details. phodav, a webdav server library,
is imported thanks to a submodule, until this project has a stable API
and releases.
The webdav channel is reponsible for handling port events and
multiplexing the request streams. Extra care has been made to avoid
blocking and to enable some fairness between concurrent streams, however
this has been particularly tricky and is likely to have some issues
left.
The webdav server is run in a seperate thread, using libsoup. The client
communication is done via a local tcp socket, but protected to only
accept local connection and with a pretty strong password.
The home directory is exported for the remote to browse, which seems to
be a sensible default atm.
I didn't understand everything (I'm confused by the soup part), but it
works, and looks good to me.
ACK series
---
.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 | 733
+++
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-session-priv.h | 3 +
gtk/spice-session.c | 1 +
spice-common | 2 +-
17 files changed, 852 insertions(+), 5 deletions(-)
create mode 100644 gtk/channel-webdav.c
create mode 100644 gtk/channel-webdav.h
create mode 16 gtk/phodav
diff --git a/.gitmodules b/.gitmodules
index 0c618ee..cfce54a 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,3 +1,6 @@
[submodule spice-common]
path = spice-common
url = ../spice-common
+[submodule gtk/phodav]
+ path = gtk/phodav
+ url = git://git.gnome.org/phodav
diff --git a/autogen.sh b/autogen.sh
index 0c18272..d71be70 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -6,6 +6,7 @@ srcdir=`dirname $0`
test -z $srcdir srcdir=.
git submodule update --init --recursive
+(cd $srcdir/gtk/phodav/ intltoolize -f)
gtkdocize
autoreconf -v --force --install
@@ -15,4 +16,3 @@ if [ -z $NOCONFIGURE ]; then
echo Running configure with --enable-maintainer-mode --enable-gtk-doc
--with-gtk=3.0 --enable-vala ${1+$@}
$srcdir/configure --enable-maintainer-mode --enable-gtk-doc
--with-gtk=3.0 --enable-vala ${1+$@}
fi
-
diff --git a/configure.ac b/configure.ac
index 192d748..d30ec40 100644
--- a/configure.ac
+++ b/configure.ac
@@ -75,6 +75,8 @@ AC_CONFIG_SUBDIRS([spice-common])
COMMON_CFLAGS='-I ${top_srcdir}/spice-common/ -I
${top_srcdir}/spice-common/spice-protocol/'
AC_SUBST(COMMON_CFLAGS)
+AC_CONFIG_SUBDIRS([gtk/phodav])
+
SPICE_GTK_MAJOR_VERSION=`echo $PACKAGE_VERSION | cut -d. -f1`
SPICE_GTK_MINOR_VERSION=`echo $PACKAGE_VERSION | cut -d. -f2`
SPICE_GTK_MICRO_VERSION=`echo $PACKAGE_VERSION | cut -d. -f3 | cut -d- -f1`
@@ -267,6 +269,8 @@ PKG_CHECK_MODULES(GTHREAD, gthread-2.0 2.0.0)
AC_SUBST(GTHREAD_CFLAGS)
AC_SUBST(GTHREAD_LIBS)
+PKG_CHECK_MODULES(SOUP, libsoup-2.4)
+
AC_ARG_WITH([audio],
AS_HELP_STRING([--with-audio=@:@gstreamer/pulse/auto/no@:@], [Select
audio backend @:@default=auto@:@]),
[],
diff --git a/doc/reference/spice-gtk-docs.xml
b/doc/reference/spice-gtk-docs.xml
index d2c1a2b..5faea74 100644
--- a/doc/reference/spice-gtk-docs.xml
+++ b/doc/reference/spice-gtk-docs.xml
@@ -37,6 +37,7 @@
xi:include href=xml/channel-smartcard.xml/
xi:include href=xml/channel-usbredir.xml/
xi:include href=xml/channel-port.xml/
+ xi:include href=xml/channel-webdav.xml/
/chapter
chapter
diff --git a/doc/reference/spice-gtk-sections.txt
b/doc/reference/spice-gtk-sections.txt
index 9232a23..caaa92c 100644
--- a/doc/reference/spice-gtk-sections.txt
+++ b/doc/reference/spice-gtk-sections.txt
@@ -461,3 +461,20 @@ spice_uri_get_type
SUBSECTION Private
SpiceURIPrivate
/SECTION
+
+SECTION
+FILEchannel-webdav/FILE
+TITLESpiceWebdavChannel/TITLE
+SpiceWebdavChannel
+SpiceWebdavChannelClass
+SUBSECTION Standard
+SPICE_IS_WEBDAV_CHANNEL
+SPICE_IS_WEBDAV_CHANNEL_CLASS
+SPICE_TYPE_WEBDAV_CHANNEL
+SPICE_WEBDAV_CHANNEL
+SPICE_WEBDAV_CHANNEL_CLASS
+SPICE_WEBDAV_CHANNEL_GET_CLASS
+spice_webdav_channel_get_type
+SUBSECTION Private
+SpiceWebdavChannelPrivate
+/SECTION
diff --git a/doc/reference/spice-gtk.types b/doc/reference/spice-gtk.types
index 2f52845..db0374a 100644
---
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
[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: [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,
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: [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
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 {
+
