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: String to ByteArray
On 11/26/2014 01:37 PM, Devesh Mishra(NABFS00) wrote: Hi, I am trying to get byteArray from a String using below code. But getting an error. var _strEncode:String = Sample String; This is a 13 byte string (no nul at the end iirc), so it seems from the error message (didn't try this code) the converted is telling you it doesn't convert partial words (a word here being 4 bytes). var _byteArr:ByteArray = new ByteArray(); var decoder:Base64Decoder = new Base64Decoder(); decoder.decode(_strEncode); _byteArr = decoder.toByteArray(); Error: A partial block (1 of 4 bytes) was dropped. Decoded data is probably truncated! Any Help ! -- Thanks Regards, Devesh Mishra ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto:mailad...@igate.com. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE please visit www.igate.com http://www.igate.com.
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: Math.pow in ActionScript
On 11/12/2014 11:23 PM, modjkl...@comcast.net wrote: For what it's worth, Matlab produces 72057594037927936. A power of 2 is not divisible by 5 and hence not by 10 so it cannot end in a zero. So any answer with a trailing zero is wrong. In general, 64-bit math is limited in accuracy to between 16 and 17 decimal digits, depending how well that number fits into a floating point representation. - Original Message - From: Gordon Smith gsmit...@hotmail.com To: users, apache users@flex.apache.org Sent: Tuesday, November 11, 2014 2:37:08 PM Subject: RE: Math.pow in ActionScript NO NO NO. 16 to the power 14 is indeed 72057594037927936. Calculator is absolutely correct. It is presumably doing high-precision integer arithmetic. ActionScript is using floating point arithmetic, since you can ask for things like Math.pow(16.1, 14.2). It doesn't special case on integers, and even if it did it doesn't do high-precision integer arithmetic. It gets the wrong answer because floating-point numbers don't have a sufficient number of significant digits to produce a 17-digit result exactly. It simply computes powers by taking the log() of the first argument, multiplying it by the second argument, and then taking the exp() of the result, because a^b = e^(ln(a^b)) = e^(b ln(a)). These are all floating-point operations. - Gordon From: javi...@gmail.com Date: Tue, 11 Nov 2014 19:48:38 +0100 Subject: Re: Math.pow in ActionScript To: users@flex.apache.org Don't worry at all about the Calculator result :) http://www.askvg.com/microsoft-windows-calculator-bug/ The math engine of the calculator is well known as quite buggy :) Once again, ActionScript is right :) On Tue, Nov 11, 2014 at 7:39 PM, OmPrakash Muppirala bigosma...@gmail.com wrote: Doing a Math.pow(16,14) in JavaScript results in 72057594037927940 as well. Google's calculator gives the same answer as well: http://lmgtfy.com/?q=16+to+the+power+of+14 Majority wins, I guess ;-) On Tue, Nov 11, 2014 at 10:25 AM, Harbs harbs.li...@gmail.com wrote: I’m not sure why you think it’s not using floats. Take a look here: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/Math.html Specifically: Note: The Math functions acos, asin, atan, atan2, cos, exp, log, pow, sin, and sqrt may result in slightly different values depending on the algorithms used by the CPU or operating system. Flash runtimes call on the CPU (or operating system if the CPU doesn't support floating point calculations) when performing the calculations for the listed functions, and results have shown slight variations depending upon the CPU or operating system in use. Harbs On Nov 11, 2014, at 7:50 PM, Devesh Mishra(NABFS00) devesh.dmis...@igate.com wrote: It's not floating point number. So I don't think so. -- Thanks Regards, Devesh Mishra -Original Message- From: Subscriptions [mailto:subscripti...@leeburrows.com] Sent: Tuesday, November 11, 2014 10:44 PM To: users@flex.apache.org Subject: Re: Math.pow in ActionScript presumably due to precision issues with large numbers (ie not your fault) eg: http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems Lee Burrows ActionScripter On 11/11/2014 16:38, Devesh Mishra(NABFS00) wrote: Hi, I am using Math.pow(x,y) method in action script. But I am very surprised with the results. For example, Math.pow(16,14). In Action Script, it gives: 72057594037927940 In Calculator, it gives: 72057594037927936 What may be the reason for this difference , Any idea ! -- Thanks Regards, Devesh Mishra ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to IGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto: mailad...@igate.com. IGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of IGATE. IGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While IGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about IGATE
FlashDevelop for multiple projects
Hi, I'm new at flash development, have tried IntelliJ and now mostly using FlashBuilder 4.7 while still trying to get a non IDE make working on linux. But this is just an introduction, I'm mostly interested in having a fast build and FlashBuilder 4.7 falls short for me (1 minute builds). I've tried FlashDevelop but the project I work on has two swc libraries and two apps using those. Does anyone use FlashDevelop for multiple projects and if so how? Thanks, Alon
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: [Qemu-devel] [PATCH 3/3] libcacard: don't free sign buffer while sign op is pending
On 10/19/2014 05:12 AM, Ray Strode wrote:
From: Ray Strode rstr...@redhat.com
commit 57f97834efe0c208ffadc9d2959f3d3d55580e52 cleaned up
the cac_applet_pki_process_apdu function to have a single
exit point. Unfortunately, that commit introduced a bug
where the sign buffer can get free'd and nullified while
it's still being used.
This commit corrects the bug by introducing a boolean to
track whether or not the sign buffer should be freed in
the function exit path.
My bad, thanks for catching this.
Reviewed-by: Alon Levy a...@pobox.com
Signed-off-by: Ray Strode rstr...@redhat.com
---
libcacard/cac.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libcacard/cac.c b/libcacard/cac.c
index ae8c378..f38fdce 100644
--- a/libcacard/cac.c
+++ b/libcacard/cac.c
@@ -88,60 +88,61 @@ cac_common_process_apdu(VCard *card, VCardAPDU *apdu,
VCardResponse **response)
}
/*
* reset the inter call state between applet selects
*/
static VCardStatus
cac_applet_pki_reset(VCard *card, int channel)
{
VCardAppletPrivate *applet_private;
CACPKIAppletData *pki_applet;
applet_private = vcard_get_current_applet_private(card, channel);
assert(applet_private);
pki_applet = (applet_private-u.pki_data);
pki_applet-cert_buffer = NULL;
g_free(pki_applet-sign_buffer);
pki_applet-sign_buffer = NULL;
pki_applet-cert_buffer_len = 0;
pki_applet-sign_buffer_len = 0;
return VCARD_DONE;
}
static VCardStatus
cac_applet_pki_process_apdu(VCard *card, VCardAPDU *apdu,
VCardResponse **response)
{
CACPKIAppletData *pki_applet;
VCardAppletPrivate *applet_private;
int size, next;
unsigned char *sign_buffer;
+bool retain_sign_buffer = FALSE;
vcard_7816_status_t status;
VCardStatus ret = VCARD_FAIL;
applet_private = vcard_get_current_applet_private(card, apdu-a_channel);
assert(applet_private);
pki_applet = (applet_private-u.pki_data);
switch (apdu-a_ins) {
case CAC_UPDATE_BUFFER:
*response = vcard_make_response(
VCARD7816_STATUS_ERROR_CONDITION_NOT_SATISFIED);
ret = VCARD_DONE;
break;
case CAC_GET_CERTIFICATE:
if ((apdu-a_p2 != 0) || (apdu-a_p1 != 0)) {
*response = vcard_make_response(
VCARD7816_STATUS_ERROR_P1_P2_INCORRECT);
break;
}
assert(pki_applet-cert != NULL);
size = apdu-a_Le;
if (pki_applet-cert_buffer == NULL) {
pki_applet-cert_buffer = pki_applet-cert;
pki_applet-cert_buffer_len = pki_applet-cert_len;
}
size = MIN(size, pki_applet-cert_buffer_len);
next = MIN(255, pki_applet-cert_buffer_len - size);
*response = vcard_response_new_bytes(
card, pki_applet-cert_buffer, size,
apdu-a_Le, next ?
@@ -151,85 +152,88 @@ cac_applet_pki_process_apdu(VCard *card, VCardAPDU
*apdu,
pki_applet-cert_buffer += size;
pki_applet-cert_buffer_len -= size;
if ((*response == NULL) || (next == 0)) {
pki_applet-cert_buffer = NULL;
}
if (*response == NULL) {
*response = vcard_make_response(
VCARD7816_STATUS_EXC_ERROR_MEMORY_FAILURE);
}
ret = VCARD_DONE;
break;
case CAC_SIGN_DECRYPT:
if (apdu-a_p2 != 0) {
*response = vcard_make_response(
VCARD7816_STATUS_ERROR_P1_P2_INCORRECT);
break;
}
size = apdu-a_Lc;
sign_buffer = g_realloc(pki_applet-sign_buffer,
pki_applet-sign_buffer_len + size);
memcpy(sign_buffer+pki_applet-sign_buffer_len, apdu-a_body, size);
size += pki_applet-sign_buffer_len;
switch (apdu-a_p1) {
case 0x80:
/* p1 == 0x80 means we haven't yet sent the whole buffer, wait
for
* the rest */
pki_applet-sign_buffer = sign_buffer;
pki_applet-sign_buffer_len = size;
*response = vcard_make_response(VCARD7816_STATUS_SUCCESS);
+retain_sign_buffer = TRUE;
break;
case 0x00:
/* we now have the whole buffer, do the operation, result will be
* in the sign_buffer */
status = vcard_emul_rsa_op(card, pki_applet-key,
sign_buffer, size);
if (status != VCARD7816_STATUS_SUCCESS) {
*response = vcard_make_response(status);
break;
}
*response = vcard_response_new(card, sign_buffer, size,
apdu-a_Le
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: [Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp
On 07/24/2014 02:12 PM, Alon Levy wrote:
From: Alon Levy al...@redhat.com
Fixed build error at glsl_parser.yy for Visual Studio 2013
Signed-off-by: Alon Levy al...@redhat.com
Not required, my bad, I was looking at an old master, patch
8c879ac1977a265ae513a5569ee3af35dbc6b1aa already does this
---
Thanks for the review. I verified and VS2013 (vs12) doesn't include
strcasecmp,
I corrected the file you mentioned, here is a better patch. (this supercedes
the previous patch)
src/mesa/main/imports.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index 9e221cc..06b460d 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -141,6 +141,9 @@ static inline float acoshf(float x) { return logf(x +
sqrtf(x * x - 1.0f)); }
static inline float atanhf(float x) { return (logf(1.0f + x) - logf(1.0f -
x)) / 2.0f; }
static inline int isblank(int ch) { return ch == ' ' || ch == '\t'; }
#define strtoll(p, e, b) _strtoi64(p, e, b)
+#endif
+
+#if defined(_MSC_VER)
#define strcasecmp(s1, s2) _stricmp(s1, s2)
#endif
/*@}*/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] gallium/u_math.h: don't redefine INFINITY and NAN in VS2013
On 07/28/2014 07:13 PM, Brian Paul wrote:
On 07/22/2014 03:07 PM, Alon Levy wrote:
Under VS2013 compiler that is distinguished by _MSC_VER of 1800 those two
are already defined, use the SDK definition.
Another option would have been to undef and use the definitions here -
I'm
not sure which is better.
---
This removes warnings, this patch is not actually required to build.
src/gallium/auxiliary/util/u_math.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index ec03e4e..60995d7 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -136,10 +136,10 @@ roundf(float x)
{
return x = 0.0f ? floorf(x + 0.5f) : ceilf(x - 0.5f);
}
-#endif
#define INFINITY (DBL_MAX + DBL_MAX)
#define NAN (INFINITY - INFINITY)
+#endif
#endif /* _MSC_VER */
This does not apply to the master branch. Neither does patch 3.
My bad, I was looking at an old branch. This is already fixed in master
by 7ebdc9e48c99a92475b48668284695663e871f7d
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp
From: Alon Levy al...@redhat.com
Fixed build error at glsl_parser.yy for Visual Studio 2013
Signed-off-by: Alon Levy al...@redhat.com
---
Thanks for the review. I verified and VS2013 (vs12) doesn't include strcasecmp,
I corrected the file you mentioned, here is a better patch. (this supercedes
the previous patch)
src/mesa/main/imports.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index 9e221cc..06b460d 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -141,6 +141,9 @@ static inline float acoshf(float x) { return logf(x +
sqrtf(x * x - 1.0f)); }
static inline float atanhf(float x) { return (logf(1.0f + x) - logf(1.0f - x))
/ 2.0f; }
static inline int isblank(int ch) { return ch == ' ' || ch == '\t'; }
#define strtoll(p, e, b) _strtoi64(p, e, b)
+#endif
+
+#if defined(_MSC_VER)
#define strcasecmp(s1, s2) _stricmp(s1, s2)
#endif
/*@}*/
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp
On 07/24/2014 02:12 PM, Alon Levy wrote:
From: Alon Levy al...@redhat.com
Forgot to add Ian as cc.
Fixed build error at glsl_parser.yy for Visual Studio 2013
Signed-off-by: Alon Levy al...@redhat.com
---
Thanks for the review. I verified and VS2013 (vs12) doesn't include
strcasecmp,
I corrected the file you mentioned, here is a better patch. (this supercedes
the previous patch)
src/mesa/main/imports.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/imports.h b/src/mesa/main/imports.h
index 9e221cc..06b460d 100644
--- a/src/mesa/main/imports.h
+++ b/src/mesa/main/imports.h
@@ -141,6 +141,9 @@ static inline float acoshf(float x) { return logf(x +
sqrtf(x * x - 1.0f)); }
static inline float atanhf(float x) { return (logf(1.0f + x) - logf(1.0f -
x)) / 2.0f; }
static inline int isblank(int ch) { return ch == ' ' || ch == '\t'; }
#define strtoll(p, e, b) _strtoi64(p, e, b)
+#endif
+
+#if defined(_MSC_VER)
#define strcasecmp(s1, s2) _stricmp(s1, s2)
#endif
/*@}*/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
On 07/24/2014 07:50 PM, Emil Velikov wrote: On 24/07/14 17:07, Matt Turner wrote: On Thu, Jul 24, 2014 at 5:44 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 23/07/14 22:16, Ian Romanick wrote: On 07/22/2014 02:07 PM, Alon Levy wrote: Signed-off-by: Alon Levy al...@redhat.com --- src/glsl/glsl_parser.yy | 4 1 file changed, 4 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index faaf438..25370cd 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -26,6 +26,10 @@ #include string.h #include assert.h +#ifdef _MSC_VER = 1800 +#define strcasecmp _stricmp +#endif + glsl_parser.yy should already get the strcasecmp work around from src/mesa/main/imports.h. Just a general question - wouldn't it be better if we move some/all these quirks around the POSIX standard(s) into a header similar to c99_compat ? ... before the amount of duplication gets out of hand. Sounds like a good idea to me, although I don't think strcasecmp is part of C99. You're absolutely correct. I was thinking about posix_compat.h (header similar to c99_compat) where he can put all the quirks needed for non POSIX compliant setups. Unfortunately I don't think I have the time for this atm. -Emil I can make a patch for just this case as a start.. If anyone has some clues as to the rest of the non posix parts and how to test that I'm not screwing anything up I can go for a fuller patch. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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
[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- ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[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
[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- ___ xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
[Mesa-dev] [PATCH 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead
Signed-off-by: Alon Levy al...@redhat.com --- src/glsl/glsl_parser.yy | 4 1 file changed, 4 insertions(+) diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy index faaf438..25370cd 100644 --- a/src/glsl/glsl_parser.yy +++ b/src/glsl/glsl_parser.yy @@ -26,6 +26,10 @@ #include string.h #include assert.h +#ifdef _MSC_VER = 1800 +#define strcasecmp _stricmp +#endif + #include ast.h #include glsl_parser_extras.h #include glsl_types.h -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] u_math.h: fix 64 to 32 bit truncation warning
Signed-off-by: Alon Levy al...@redhat.com --- This file is common so this warning comes up a lot. src/gallium/auxiliary/util/u_math.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/util/u_math.h b/src/gallium/auxiliary/util/u_math.h index 60995d7..7c1ac4a 100644 --- a/src/gallium/auxiliary/util/u_math.h +++ b/src/gallium/auxiliary/util/u_math.h @@ -760,7 +760,7 @@ util_bswap64(uint64_t n) #if defined(HAVE___BUILTIN_BSWAP64) return __builtin_bswap64(n); #else - return ((uint64_t)util_bswap32(n) 32) | + return ((uint64_t)util_bswap32((uint32_t)n) 32) | util_bswap32((n 32)); #endif } -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] gallium/u_debug_flush.c: fix build error for vs12
use util_snprintf that is already defined in other systems by u_string.h
to as snprintf, so to not change behavior in other systems.
Signed-off-by: Alon Levy al...@redhat.com
---
src/gallium/auxiliary/util/u_debug_flush.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_debug_flush.c
b/src/gallium/auxiliary/util/u_debug_flush.c
index 9cf70db..fdb248c 100644
--- a/src/gallium/auxiliary/util/u_debug_flush.c
+++ b/src/gallium/auxiliary/util/u_debug_flush.c
@@ -46,6 +46,7 @@
#include util/u_hash_table.h
#include util/u_double_list.h
#include util/u_inlines.h
+#include util/u_string.h
#include os/os_thread.h
#include stdio.h
@@ -320,8 +321,8 @@ debug_flush_might_flush_cb(void *key, void *value, void
*data)
const char *reason = (const char *) data;
char message[80];
- snprintf(message, sizeof(message),
-%s referenced mapped buffer detected., reason);
+ util_snprintf(message, sizeof(message),
+ %s referenced mapped buffer detected., reason);
pipe_mutex_lock(fbuf-mutex);
if (fbuf-mapped_sync) {
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/7] vs12 cleanup patches
Hi, These patches include some actual fixes for building target libgl-gdi with scons, and some warning removal (there are a ton left I didn't pursue - mostly truncation warnings and sign warnings). Not related to the patchset, but important for anyone building libgl-gdi (i.e. opengl32.dll) scons 2.3.2 seems broken wrt def files, I opened issue http://scons.tigris.org/issues/show_bug.cgi?id=2966 and used the patch included there to successfully build the dll. Alon Alon Levy (7): gallium/u_math.h: don't redefine INFINITY and NAN in VS2013 glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead gallium/u_debug_flush.c: fix build error for vs12 u_math.h: fix 64 to 32 bit truncation warning wgl: stw_pixelformat_get_info: correct type for index variable glsl: fix inconsistent struct/class warning in vs12 mesa/shaderimage.c: fix inconsistent sign warning src/gallium/auxiliary/util/u_debug_flush.c | 5 +++-- src/gallium/auxiliary/util/u_math.h | 4 ++-- src/gallium/state_trackers/wgl/stw_pixelformat.c | 2 +- src/glsl/glsl_parser.yy | 4 src/glsl/opt_dead_builtin_varyings.cpp | 2 +- src/mesa/main/shaderimage.c | 2 +- 6 files changed, 12 insertions(+), 7 deletions(-) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] gallium/u_math.h: don't redefine INFINITY and NAN in VS2013
Under VS2013 compiler that is distinguished by _MSC_VER of 1800 those two
are already defined, use the SDK definition.
Another option would have been to undef and use the definitions here - I'm
not sure which is better.
---
This removes warnings, this patch is not actually required to build.
src/gallium/auxiliary/util/u_math.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index ec03e4e..60995d7 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -136,10 +136,10 @@ roundf(float x)
{
return x = 0.0f ? floorf(x + 0.5f) : ceilf(x - 0.5f);
}
-#endif
#define INFINITY (DBL_MAX + DBL_MAX)
#define NAN (INFINITY - INFINITY)
+#endif
#endif /* _MSC_VER */
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/7] glsl: fix inconsistent struct/class warning in vs12
Remove incorrect struct prefix, ir_variable is a class Signed-off-by: Alon Levy al...@redhat.com --- src/glsl/opt_dead_builtin_varyings.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/glsl/opt_dead_builtin_varyings.cpp b/src/glsl/opt_dead_builtin_varyings.cpp index c2a306e..f98a21f 100644 --- a/src/glsl/opt_dead_builtin_varyings.cpp +++ b/src/glsl/opt_dead_builtin_varyings.cpp @@ -334,7 +334,7 @@ public: } void prepare_array(exec_list *ir, - struct ir_variable **new_var, + ir_variable **new_var, int max_elements, unsigned start_location, const char *var_name, const char *mode_str, unsigned usage, unsigned external_usage) -- 1.9.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] wgl: stw_pixelformat_get_info: correct type for index variable
Signed-off-by: Alon Levy al...@redhat.com
---
src/gallium/state_trackers/wgl/stw_pixelformat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/wgl/stw_pixelformat.c
b/src/gallium/state_trackers/wgl/stw_pixelformat.c
index 1ef302d..7e5561b 100644
--- a/src/gallium/state_trackers/wgl/stw_pixelformat.c
+++ b/src/gallium/state_trackers/wgl/stw_pixelformat.c
@@ -297,7 +297,7 @@ stw_pixelformat_get_extended_count( void )
const struct stw_pixelformat_info *
stw_pixelformat_get_info( int iPixelFormat )
{
- int index;
+ unsigned index;
if (iPixelFormat = 0) {
return NULL;
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] mesa/shaderimage.c: fix inconsistent sign warning
Signed-off-by: Alon Levy al...@redhat.com
---
src/mesa/main/shaderimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
index d1e752d..298ede2 100644
--- a/src/mesa/main/shaderimage.c
+++ b/src/mesa/main/shaderimage.c
@@ -383,7 +383,7 @@ validate_image_unit(struct gl_context *ctx, struct
gl_image_unit *u)
void
_mesa_validate_image_units(struct gl_context *ctx)
{
- int i;
+ unsigned i;
for (i = 0; i ctx-Const.MaxImageUnits; ++i) {
struct gl_image_unit *u = ctx-ImageUnits[i];
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
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: [Qemu-devel] [PATCH] ccid-card-emulated: use EventNotifier
Shut up Coverity's complaint about unchecked fcntl return values,
and especially make the code simpler and more efficient.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Alon Levy al...@redhat.com
one question below.
---
hw/usb/ccid-card-emulated.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/hw/usb/ccid-card-emulated.c b/hw/usb/ccid-card-emulated.c
index 7213c89..aa1c37a 100644
--- a/hw/usb/ccid-card-emulated.c
+++ b/hw/usb/ccid-card-emulated.c
@@ -126,7 +126,7 @@ struct EmulatedState {
QemuMutex vreader_mutex; /* and guest_apdu_list mutex */
QemuMutex handle_apdu_mutex;
QemuCond handle_apdu_cond;
-int pipe[2];
+EventNotifier notifier;
int quit_apdu_thread;
QemuThread apdu_thread_id;
};
@@ -162,9 +162,7 @@ static void emulated_push_event(EmulatedState *card,
EmulEvent *event)
qemu_mutex_lock(card-event_list_mutex);
QSIMPLEQ_INSERT_TAIL((card-event_list), event, entry);
qemu_mutex_unlock(card-event_list_mutex);
-if (write(card-pipe[1], card, 1) != 1) {
-DPRINTF(card, 1, write to pipe failed\n);
-}
+event_notifier_set(card-notifier);
}
static void emulated_push_type(EmulatedState *card, uint32_t type)
@@ -358,16 +356,12 @@ static void *event_thread(void *arg)
return NULL;
}
-static void pipe_read(void *opaque)
+static void card_event_handler(EventNotifier *notifier)
{
-EmulatedState *card = opaque;
+EmulatedState *card = container_of(notifier, EmulatedState, notifier);
EmulEvent *event, *next;
-char dummy;
-int len;
-do {
-len = read(card-pipe[0], dummy, sizeof(dummy));
-} while (len == sizeof(dummy));
+event_notifier_test_and_clear(card-notifier);
Shouldn't the ignored return value be marked somehow?
qemu_mutex_lock(card-event_list_mutex);
QSIMPLEQ_FOREACH_SAFE(event, card-event_list, entry, next) {
DPRINTF(card, 2, event %s\n,
emul_event_to_string(event-p.gen.type));
@@ -404,16 +398,13 @@ static void pipe_read(void *opaque)
qemu_mutex_unlock(card-event_list_mutex);
}
-static int init_pipe_signaling(EmulatedState *card)
+static int init_event_notifier(EmulatedState *card)
{
-if (pipe(card-pipe) 0) {
-DPRINTF(card, 2, pipe creation failed\n);
+if (event_notifier_init(card-notifier, false) 0) {
+DPRINTF(card, 2, event notifier creation failed\n);
return -1;
}
-fcntl(card-pipe[0], F_SETFL, O_NONBLOCK);
-fcntl(card-pipe[1], F_SETFL, O_NONBLOCK);
-fcntl(card-pipe[0], F_SETOWN, getpid());
-qemu_set_fd_handler(card-pipe[0], pipe_read, NULL, card);
+event_notifier_set_handler(card-notifier, card_event_handler);
return 0;
}
@@ -500,7 +491,7 @@ static int emulated_initfn(CCIDCardState *base)
qemu_cond_init(card-handle_apdu_cond);
card-reader = NULL;
card-quit_apdu_thread = 0;
-if (init_pipe_signaling(card) 0) {
+if (init_event_notifier(card) 0) {
return -1;
}
--
1.9.3
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
Re: [Qemu-devel] [PATCH] libcacard: improve documentation
On 05/28/2014 07:15 PM, Paolo Bonzini wrote: Using the file-backed smartcard backend is black magic, but it can be useful if your only smartcard bricks itself if it is accessed the wrong way too many times. Complete the documentation to include the art of creating certificates and using them with QEMU, based on Ray Strode's useful tutorial at https://blogs.gnome.org/halfline/2013/09/08/another-smartcard-post/ but with ccid-card-emulated or vscclient instead of SPICE. Cc: Alon Levy al...@redhat.com Cc: Ray Strode rstr...@redhat.com Did you mean Robert Relyea rrel...@redhat.com ? Thanks, looks good. Reviewed-by: Alon Levy al...@redhat.com Signed-off-by: Paolo Bonzini pbonz...@redhat.com --- docs/ccid.txt | 80 ++- 1 file changed, 63 insertions(+), 17 deletions(-) diff --git a/docs/ccid.txt b/docs/ccid.txt index 83c174d..c7fda6d 100644 --- a/docs/ccid.txt +++ b/docs/ccid.txt @@ -47,6 +47,7 @@ In ubuntu/debian: Configuring and building: ./configure --enable-smartcard make + 3. Using ccid-card-emulated with hardware Assuming you have a working smartcard on the host with the current @@ -54,19 +55,55 @@ user, using NSS, qemu acts as another NSS client using ccid-card-emulated: qemu -usb -device usb-ccid -device ccid-card-emulated -4. Using ccid-card-emulated with certificates -You must create the certificates. This is a one time process. We use NSS -certificates: +4. Using ccid-card-emulated with certificates stored in files + +You must create the CA and card certificates. This is a one time process. +We use NSS certificates: -certutil -d /etc/pki/nssdb -x -t CT,CT,CT -S -s CN=cert1 -n cert1 +mkdir fake-smartcard +cd fake-smartcard +certutil -N -d sql:$PWD +certutil -S -d sql:$PWD -s CN=Fake Smart Card CA -x -t TC,TC,TC -n fake-smartcard-ca +certutil -S -d sql:$PWD -t ,, -s CN=John Doe -n id-cert -c fake-smartcard-ca +certutil -S -d sql:$PWD -t ,, -s CN=John Doe (signing) --nsCertType smime -n signing-cert -c fake-smartcard-ca +certutil -S -d sql:$PWD -t ,, -s CN=John Doe (encryption) --nsCertType sslClient -n encryption-cert -c fake-smartcard-ca Note: you must have exactly three certificates. -Assuming the current user can access the certificates (use certutil -L to -verify), you can use the emulated card type with the certificates backend: +You can use the emulated card type with the certificates backend: + +qemu -usb -device usb-ccid -device ccid-card-emulated,backend=certificates,db=sql:$PWD,cert1=id-cert,cert2=signing-cert,cert3=encryption-cert + +To use the certificates in the guest, export the CA certificate: + +certutil -L -r -d sql:$PWD -o fake-smartcard-ca.cer -n fake-smartcard-ca + +and import it in the guest: + +certutil -A -d /etc/pki/nssdb -i fake-smartcard-ca.cer -t TC,TC,TC -n fake-smartcard-ca + +In a Linux guest you can then use the CoolKey PKCS #11 module to access +the card: + +certutil -d /etc/pki/nssdb -L -h all + +It will prompt you for the PIN (which is the password you assigned to the +certificate database early on), and then show you all three certificates +together with the manually imported CA cert: + +Certificate NicknameTrust Attributes +fake-smartcard-ca CT,C,C +John Doe:CAC ID Certificate u,u,u +John Doe:CAC Email Signature Certificateu,u,u +John Doe:CAC Email Encryption Certificate u,u,u + +If this does not happen, CoolKey is not installed or not registered with +NSS. Registration can be done from Firefox or the command line: + +modutil -dbdir /etc/pki/nssdb -add CAC Module -libfile /usr/lib64/pkcs11/libcoolkeypk11.so +modutil -dbdir /etc/pki/nssdb -list -qemu -usb -device usb-ccid -device ccid-card-emulated,backend=certificates,cert1=cert1,cert2=cert2,cert3=cert3 5. Using ccid-card-passthru with client side hardware @@ -74,15 +111,23 @@ on the host specify the ccid-card-passthru device with a suitable chardev: qemu -chardev socket,server,host=0.0.0.0,port=2001,id=ccid,nowait -usb -device usb-ccid -device ccid-card-passthru,chardev=ccid -on the client run vscclient, built when you built the libcacard library: -libcacard/vscclient qemu-host 2001 +on the client run vscclient, built when you built QEMU: + +vscclient qemu-host 2001 + 6. Using ccid-card-passthru with client side certificates -Run qemu as per #5, and run vscclient as follows: -(Note: vscclient command line interface is in a state of change) +This case is not particularly useful, but you can use it to debug +your setup if #4 works but #5 does not. + +Follow instructions as per #4, except run QEMU and vscclient as follows: +Run qemu as per #5, and run vscclient from the fake-smartcard +directory as follows
Re: [Qemu-devel] [Qemu-trivial] [PATCH] libcacard: remove useless initializers
On 05/23/2014 11:59 PM, Michael Tokarev wrote: So, should we apply this or not? It's been waiting for quite some time, and during this time we've found a very good example of why it should be applied (I think anyway). I'm fine with applying it, I changed my mind. Thanks, /mjt 12.05.2014 13:20, Markus Armbruster wrote: Michael Tokarev m...@tls.msk.ru writes: 11.05.2014 11:58, Alon Levy wrote: On 05/08/2014 08:19 PM, Michael Tokarev wrote: libcacard has many functions which initializes local variables at declaration time, which are always assigned some values later (often right after declaration). Clean up these initializers. How is this an improvement? Doesn't the compiler ignore this anyhow? Just less code. To me, when I see something like Type *var = NULL; in a function, it somehow translates to a construct like Type *found = NULL; That is -- so this variable will be used either as an accumulator or a search result, so that initial value is really important. So when I see the same variable receives its initial value in the next line, I start wondering what's missed in the code which should be there. Or why I don't read the code correctly. Or something like this. So, basically, this is a cleanup patch just to avoid confusion, it most likely not needed for current compiler who can figure it out by its own. And for consistency - why not initialize other variables too? I hate redundant initializers for yet another reason: when I change the code, and accidentally add a path bypassing the *real* initialization, I don't get a may be used uninitialized warning, I get the stupid redundant initialization and quite possibly a crash to debug some time later. Maybe that's just my old-scool mind works this way. At any rate you can just ignore this patch. Please consider it.
Re: [Qemu-devel] [PATCH 0/7] libcacard: A few simple fixes and cleanups
On 05/22/2014 05:57 PM, Markus Armbruster wrote: Makes Coverity happy with libcacard/ (for now). Markus Armbruster (7): libcacard/vscclient: Bury some dead code libcacard: Plug memory leaks around vreader_get_reader_list() libcacard/vreader: Drop broken recovery from failed assertion libcacard/vreader: Tighten assertion to clarify intent libcacard: Convert two leftover realloc() to GLib libcacard/vcard_emul_nss: Assert vreaderOpt isn't null libcacard/vcard_emul_nss: Drop a redundant conditional libcacard/cac.c| 13 ++--- libcacard/vcard_emul_nss.c | 16 ++-- libcacard/vreader.c| 10 -- libcacard/vscclient.c | 7 +++ 4 files changed, 15 insertions(+), 31 deletions(-) Reviewed-by: Alon Levy al...@redhat.com
[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: [Qemu-devel] [PATCH] libcacard: remove useless initializers
On 05/08/2014 08:19 PM, Michael Tokarev wrote:
libcacard has many functions which initializes local variables
at declaration time, which are always assigned some values later
(often right after declaration). Clean up these initializers.
How is this an improvement? Doesn't the compiler ignore this anyhow?
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
libcacard/cac.c| 14 +++---
libcacard/card_7816.c |5 ++---
libcacard/vcard.c |4 ++--
libcacard/vcard_emul_nss.c |6 +++---
libcacard/vreader.c| 10 +-
libcacard/vscclient.c |4 ++--
6 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/libcacard/cac.c b/libcacard/cac.c
index 122129e..d1d9ee2 100644
--- a/libcacard/cac.c
+++ b/libcacard/cac.c
@@ -93,8 +93,8 @@ cac_common_process_apdu(VCard *card, VCardAPDU *apdu,
VCardResponse **response)
static VCardStatus
cac_applet_pki_reset(VCard *card, int channel)
{
-VCardAppletPrivate *applet_private = NULL;
-CACPKIAppletData *pki_applet = NULL;
+VCardAppletPrivate *applet_private;
+CACPKIAppletData *pki_applet;
applet_private = vcard_get_current_applet_private(card, channel);
assert(applet_private);
pki_applet = (applet_private-u.pki_data);
@@ -113,8 +113,8 @@ static VCardStatus
cac_applet_pki_process_apdu(VCard *card, VCardAPDU *apdu,
VCardResponse **response)
{
-CACPKIAppletData *pki_applet = NULL;
-VCardAppletPrivate *applet_private = NULL;
+CACPKIAppletData *pki_applet;
+VCardAppletPrivate *applet_private;
int size, next;
unsigned char *sign_buffer;
vcard_7816_status_t status;
@@ -288,7 +288,7 @@ cac_applet_container_process_apdu(VCard *card, VCardAPDU
*apdu,
static void
cac_delete_pki_applet_private(VCardAppletPrivate *applet_private)
{
-CACPKIAppletData *pki_applet_data = NULL;
+CACPKIAppletData *pki_applet_data;
if (applet_private == NULL) {
return;
@@ -336,8 +336,8 @@ static VCardApplet *
cac_new_pki_applet(int i, const unsigned char *cert,
int cert_len, VCardKey *key)
{
-VCardAppletPrivate *applet_private = NULL;
-VCardApplet *applet = NULL;
+VCardAppletPrivate *applet_private;
+VCardApplet *applet;
unsigned char pki_aid[] = { 0xa0, 0x00, 0x00, 0x00, 0x79, 0x01, 0x00 };
int pki_aid_len = sizeof(pki_aid);
diff --git a/libcacard/card_7816.c b/libcacard/card_7816.c
index bca8c4a..a54f880 100644
--- a/libcacard/card_7816.c
+++ b/libcacard/card_7816.c
@@ -416,7 +416,7 @@
VCARD_RESPONSE_NEW_STATIC_STATUS(VCARD7816_STATUS_ERROR_GENERAL)
VCardResponse *
vcard_make_response(vcard_7816_status_t status)
{
-VCardResponse *response = NULL;
+VCardResponse *response;
switch (status) {
/* known 7816 response codes */
@@ -543,9 +543,8 @@ vcard_make_response(vcard_7816_status_t status)
return VCARD_RESPONSE_GET_STATIC(
VCARD7816_STATUS_EXC_ERROR_MEMORY_FAILURE);
}
+return response;
}
-assert(response);
-return response;
}
/*
diff --git a/libcacard/vcard.c b/libcacard/vcard.c
index 227e477..6aaf085 100644
--- a/libcacard/vcard.c
+++ b/libcacard/vcard.c
@@ -166,8 +166,8 @@ vcard_reference(VCard *vcard)
void
vcard_free(VCard *vcard)
{
-VCardApplet *current_applet = NULL;
-VCardApplet *next_applet = NULL;
+VCardApplet *current_applet;
+VCardApplet *next_applet;
if (vcard == NULL) {
return;
diff --git a/libcacard/vcard_emul_nss.c b/libcacard/vcard_emul_nss.c
index 75b9d79..3f38a4c 100644
--- a/libcacard/vcard_emul_nss.c
+++ b/libcacard/vcard_emul_nss.c
@@ -367,7 +367,7 @@ vcard_7816_status_t
vcard_emul_login(VCard *card, unsigned char *pin, int pin_len)
{
PK11SlotInfo *slot;
-unsigned char *pin_string = NULL;
+unsigned char *pin_string;
int i;
SECStatus rv;
@@ -423,7 +423,7 @@ static VReader *
vcard_emul_find_vreader_from_slot(PK11SlotInfo *slot)
{
VReaderList *reader_list = vreader_get_reader_list();
-VReaderListEntry *current_entry = NULL;
+VReaderListEntry *current_entry;
if (reader_list == NULL) {
return NULL;
@@ -1050,7 +1050,7 @@ void
vcard_emul_replay_insertion_events(void)
{
VReaderListEntry *current_entry;
-VReaderListEntry *next_entry = NULL;
+VReaderListEntry *next_entry;
VReaderList *list = vreader_get_reader_list();
for (current_entry = vreader_list_get_first(list); current_entry;
diff --git a/libcacard/vreader.c b/libcacard/vreader.c
index 9304a28..22dfe43 100644
--- a/libcacard/vreader.c
+++ b/libcacard/vreader.c
@@ -341,7 +341,7 @@ void
vreader_list_delete(VReaderList *list)
{
VReaderListEntry *current_entry;
-VReaderListEntry *next_entry = NULL;
+VReaderListEntry *next_entry;
Re: [Qemu-devel] [PATCH] libcacard: g_malloc cleanups
On 05/08/2014 06:54 PM, Michael Tokarev wrote:
This patch replaces g_malloc() in libcacard into g_new()
or g_new0() where appropriate (removing some init-to-zero
surrounding code), g_malloc+memcpy into g_memdup() and the
like.
Reviewed-by: Alon Levy al...@redhat.com
just one comment below.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
libcacard/cac.c| 11 +++
libcacard/card_7816.c | 11 +--
libcacard/event.c |2 +-
libcacard/vcard.c | 22 +-
libcacard/vcard_emul_nss.c | 12 ++--
libcacard/vreader.c| 11 +++
6 files changed, 23 insertions(+), 46 deletions(-)
diff --git a/libcacard/cac.c b/libcacard/cac.c
index 74ef3e3..122129e 100644
--- a/libcacard/cac.c
+++ b/libcacard/cac.c
@@ -310,16 +310,11 @@ static VCardAppletPrivate *
cac_new_pki_applet_private(const unsigned char *cert,
int cert_len, VCardKey *key)
{
-CACPKIAppletData *pki_applet_data = NULL;
-VCardAppletPrivate *applet_private = NULL;
These two lines above (and the corresponding ones beloow) seem unrelated
to this patch.
-applet_private = (VCardAppletPrivate
*)g_malloc(sizeof(VCardAppletPrivate));
+CACPKIAppletData *pki_applet_data;
+VCardAppletPrivate *applet_private;
+applet_private = g_new0(VCardAppletPrivate, 1);
pki_applet_data = (applet_private-u.pki_data);
-pki_applet_data-cert_buffer = NULL;
-pki_applet_data-cert_buffer_len = 0;
-pki_applet_data-sign_buffer = NULL;
-pki_applet_data-sign_buffer_len = 0;
-pki_applet_data-key = NULL;
pki_applet_data-cert = (unsigned char *)g_malloc(cert_len+1);
/*
* if we want to support compression, then we simply change the 0 to a 1
diff --git a/libcacard/card_7816.c b/libcacard/card_7816.c
index c28bb60..bca8c4a 100644
--- a/libcacard/card_7816.c
+++ b/libcacard/card_7816.c
@@ -51,7 +51,7 @@ vcard_response_new_data(unsigned char *buf, int len)
{
VCardResponse *new_response;
-new_response = (VCardResponse *)g_malloc(sizeof(VCardResponse));
+new_response = g_new(VCardResponse, 1);
new_response-b_data = g_malloc(len + 2);
memcpy(new_response-b_data, buf, len);
new_response-b_total_len = len+2;
@@ -132,7 +132,7 @@ vcard_response_new_status(vcard_7816_status_t status)
{
VCardResponse *new_response;
-new_response = (VCardResponse *)g_malloc(sizeof(VCardResponse));
+new_response = g_new(VCardResponse, 1);
new_response-b_data = new_response-b_sw1;
new_response-b_len = 0;
new_response-b_total_len = 2;
@@ -149,7 +149,7 @@ vcard_response_new_status_bytes(unsigned char sw1,
unsigned char sw2)
{
VCardResponse *new_response;
-new_response = (VCardResponse *)g_malloc(sizeof(VCardResponse));
+new_response = g_new(VCardResponse, 1);
new_response-b_data = new_response-b_sw1;
new_response-b_len = 0;
new_response-b_total_len = 2;
@@ -336,9 +336,8 @@ vcard_apdu_new(unsigned char *raw_apdu, int len,
vcard_7816_status_t *status)
return NULL;
}
-new_apdu = (VCardAPDU *)g_malloc(sizeof(VCardAPDU));
-new_apdu-a_data = g_malloc(len);
-memcpy(new_apdu-a_data, raw_apdu, len);
+new_apdu = g_new(VCardAPDU, 1);
+new_apdu-a_data = g_memdup(raw_apdu, len);
new_apdu-a_len = len;
*status = vcard_apdu_set_class(new_apdu);
if (*status != VCARD7816_STATUS_SUCCESS) {
diff --git a/libcacard/event.c b/libcacard/event.c
index 2d7500f..a2e6c7d 100644
--- a/libcacard/event.c
+++ b/libcacard/event.c
@@ -17,7 +17,7 @@ vevent_new(VEventType type, VReader *reader, VCard *card)
{
VEvent *new_vevent;
-new_vevent = (VEvent *)g_malloc(sizeof(VEvent));
+new_vevent = g_new(VEvent, 1);
new_vevent-next = NULL;
new_vevent-type = type;
new_vevent-reader = vreader_reference(reader);
diff --git a/libcacard/vcard.c b/libcacard/vcard.c
index 539177b..227e477 100644
--- a/libcacard/vcard.c
+++ b/libcacard/vcard.c
@@ -37,9 +37,8 @@ vcard_buffer_response_new(unsigned char *buffer, int size)
{
VCardBufferResponse *new_buffer;
-new_buffer = (VCardBufferResponse
*)g_malloc(sizeof(VCardBufferResponse));
-new_buffer-buffer = (unsigned char *)g_malloc(size);
-memcpy(new_buffer-buffer, buffer, size);
+new_buffer = g_new(VCardBufferResponse, 1);
+new_buffer-buffer = (unsigned char *)g_memdup(buffer, size);
new_buffer-buffer_len = size;
new_buffer-current = new_buffer-buffer;
new_buffer-len = size;
@@ -102,15 +101,11 @@ vcard_new_applet(VCardProcessAPDU
applet_process_function,
{
VCardApplet *applet;
-applet = (VCardApplet *)g_malloc(sizeof(VCardApplet));
-applet-next = NULL;
-applet-applet_private = NULL;
-applet-applet_private_free = NULL;
+applet = g_new0(VCardApplet, 1);
applet
Re: [Qemu-devel] [PATCH 0/5] glib thread interface and libcacard cleanups
On 05/05/2014 07:36 PM, Michael Tokarev wrote: 05.05.2014 18:49, Alon Levy wrote: On 04/29/2014 09:02 AM, Michael Tokarev wrote: Basically libgthread has been rewritten in glib version 2.31, and old ways to use thread primitives stopped working while new ways appeared. The two interfaces were sufficiently different to warrant large ifdeffery across all code using it. [...] [] Reviewed-by: Alon Levy al...@redhat.com Tested-by: Alon Levy al...@redhat.com Hmm. Now I'm a bit confused. Which version did you test? :) I posted a v2 patch which splits one of the changes into two (pstrcpy to memcpy conversion in libcacard), added some more (minor) changes (which should not affect libcacard code in any way), and adjusted commit messages. The main code is not affected (or should not be), so Tested-by probably may stay, except of the pstrcpy to memcpy patch (http://patchwork.ozlabs.org/patch/345002/) which may affect libcacard. Here's the v2: http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00286.html If you tested the git branch which I referred to, that's the v2, not original submission which you're replying to. I've tested and reviewed 7191b2c43eecc52994924245720c534ea1a0dc84 so v2, my bad. This would be nice to have too (it has nothing to do with your patchset, but it would save me a pull request): commit 2fc95f8bc1912e2de243389d9d102a5a28267f31 Author: Alon Levy al...@redhat.com Date: Mon May 5 17:41:32 2014 +0300 libcacard: remove unnecessary EOL from debug prints Well, this can easily go to -trivial, as I'm planning to send a pull request for it soon anyway. Thank you! /mjt
Re: [Qemu-devel] [PATCH 0/5] glib thread interface and libcacard cleanups
to be strict, exporting only really necessary
symbols, omitting internal symbols. Previously, libcacard used and
exported many of qemu internals, including thread functions. Now
it not only stopped exporting them, but also stopped using them.
The whole thing has been compile-tested with both new and old glib
versions on linux and FreeBSD, and runtime-tested on linux (again,
both old and new versions) with --with-coroutine=gthread. I didn't
test libcacard much, because I found no testcases for it, but at
least it _appears_ to work.
The diffstat below does not look like a diffstat of a cleanup, because
the patchset adds about 2 times more lines than it removes. This is
because of large addition to glib-compat.h, plus addition of compat
code to vscclient, to make it independent of qemu.
and a few others.
Thanks,
Reviewed-by: Alon Levy al...@redhat.com
Tested-by: Alon Levy al...@redhat.com
This would be nice to have too (it has nothing to do with your patchset,
but it would save me a pull request):
commit 2fc95f8bc1912e2de243389d9d102a5a28267f31
Author: Alon Levy al...@redhat.com
Date: Mon May 5 17:41:32 2014 +0300
libcacard: remove unnecessary EOL from debug prints
Signed-off-by: Alon Levy al...@redhat.com
diff --git a/libcacard/vreader.c b/libcacard/vreader.c
index 91799b4..d1e05af 100644
--- a/libcacard/vreader.c
+++ b/libcacard/vreader.c
@@ -272,12 +272,12 @@ vreader_xfr_bytes(VReader *reader,
response = vcard_make_response(status);
card_status = VCARD_DONE;
} else {
-g_debug(%s: CLS=0x%x,INS=0x%x,P1=0x%x,P2=0x%x,Lc=%d,Le=%d %s\n,
+g_debug(%s: CLS=0x%x,INS=0x%x,P1=0x%x,P2=0x%x,Lc=%d,Le=%d %s,
__func__, apdu-a_cla, apdu-a_ins, apdu-a_p1, apdu-a_p2,
apdu-a_Lc, apdu-a_Le, apdu_ins_to_string(apdu-a_ins));
card_status = vcard_process_apdu(card, apdu, response);
if (response) {
-g_debug(%s: status=%d sw1=0x%x sw2=0x%x len=%d (total=%d)\n,
+g_debug(%s: status=%d sw1=0x%x sw2=0x%x len=%d (total=%d),
__func__, response-b_status, response-b_sw1,
response-b_sw2, response-b_len, response-b_total_len);
}
/mjt
Michael Tokarev (5):
do not call g_thread_init() for glib = 2.31
glib-compat.h: add new thread API emulation on top of pre-2.31 API
vscclient: use glib thread primitives not qemu
libcacard: replace qemu thread primitives with glib ones
libcacard: actually use symbols file
coroutine-gthread.c| 37 ++--
include/glib-compat.h | 103
libcacard/Makefile | 10 +
libcacard/event.c | 25 ++-
libcacard/vcard_emul_nss.c |3 +-
libcacard/vreader.c| 19
libcacard/vscclient.c | 75 +++-
trace/simple.c | 50 ++---
util/osdep.c | 21 -
9 files changed, 206 insertions(+), 137 deletions(-)
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: [Qemu-devel] [PATCH] libcacard: actually use the symbols file
On 04/21/2014 12:09 PM, Michael Tokarev wrote: 21.04.2014 13:01, Michael Tokarev wrote: libtool has an argument for .syms file, which is -export-symbols. There's no argument `-export-syms', and it looks like at least on linux, -export-syms is just ignored. Use the correct argument, -export-symbols, to actually get the right export list. Note: with this patch applied, linking vscclient fails due to the following symbols missing: qemu_mutex_lock qemu_mutex_unlock qemu_cond_wait qemu_cond_signal qemu_thread_create socket_init qemu_socket qemu_mutex_init qemu_cond_init So it looks like a preparation patch is needed before this one, to ensure bisectability. Should those symbols be exported by libcacard (hence listed in the .syms file), or should vscclient link line use more objects? They should not be exported by libcacard. I'm not sure what is happening here except to note that the list of objects being linked must satisfy all missing symbols since it results in a loadable and executable executable. Thanks, /mjt Signed-off-by: Michael Tokarev m...@tls.msk.ru --- libcacard/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libcacard/Makefile b/libcacard/Makefile index 6b06448..ca08991 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -24,7 +24,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la # Rules for building libcacard standalone library libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ --export-syms $(SRC_PATH)/libcacard/libcacard.syms +-export-symbols $(SRC_PATH)/libcacard/libcacard.syms libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^)
Re: [Qemu-devel] [PATCH] libcacard: actually use symbols file
On 04/27/2014 05:37 PM, Michael Tokarev wrote: libtool has an argument for .syms file, which is -export-symbols. There's no argument `-export-syms', and it looks like at least on linux, -export-syms is just ignored. Use the correct argument, -export-symbols, to actually get the right export list. But it turns out that vscclient binary, which also uses qemu privitives for sockets, mutexes and some other stuff, but only linked with libcacard, does not link after hiding extra symbols previously exported by libcacard. So while at it, link it with libqemuutil.a and libqemustub.a. This makes the binary as twice as large, but allows to have cleaner export table for libcacard.so. Reviewed-by: Alon Levy al...@redhat.com Any chance to get this through the trivial patch queue? Signed-off-by: Michael Tokarev m...@tls.msk.ru --- libcacard/Makefile |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libcacard/Makefile b/libcacard/Makefile index 6b06448..bb00c94 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -17,14 +17,14 @@ $(libcacard-obj-y): | $(libcacard-lobj-y) all: libcacard.la libcacard.pc -vscclient$(EXESUF): libcacard/vscclient.o libcacard.la +vscclient$(EXESUF): libcacard/vscclient.o libcacard.la libqemuutil.a libqemustub.a $(call LINK,$^) # # Rules for building libcacard standalone library libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ - -export-syms $(SRC_PATH)/libcacard/libcacard.syms + -export-symbols $(SRC_PATH)/libcacard/libcacard.syms libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^)
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
[Qemu-devel] [PATCH] display/qxl: don't abort on reset with non empty rings
The command ring and cursor rings are pushed to by the guest, and
cleared asynchronously by qemu's spice thread. It is easy to have
them non empty by bad guest behaviour, and we must never abort on bad
guest behaviour.
Signed-off-by: Alon Levy al...@redhat.com
---
hw/display/qxl.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 47bbf1f..abe7a18 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -,8 +,12 @@ static void qxl_check_state(PCIQXLDevice *d)
QXLRam *ram = d-ram;
int spice_display_running = qemu_spice_display_is_running(d-ssd);
-assert(!spice_display_running || SPICE_RING_IS_EMPTY(ram-cmd_ring));
-assert(!spice_display_running || SPICE_RING_IS_EMPTY(ram-cursor_ring));
+if (spice_display_running !SPICE_RING_IS_EMPTY(ram-cmd_ring)) {
+fprintf(stderr, qxl: cmd ring not empty on reset\n);
+}
+if (spice_display_running !SPICE_RING_IS_EMPTY(ram-cursor_ring)) {
+fprintf(stderr, qxl: cursor ring not empty on reset\n);
+}
}
static void qxl_reset_state(PCIQXLDevice *d)
--
1.8.5.3
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
---
