Re: [Spice-devel] [PATCH] usbredirparser: prevent endless recursion if interface_count == 0

[Alon Levy]

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

[Alon Levy]

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

[Alon Levy]

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

[Alon Levy]

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.

[Alon Levy]

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

[Alon Levy]

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] [PATCH spice-protocol] build-sys: simplify autogen

[Alon Levy]

[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] Spice agent and LXC

[Alon Levy]

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  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

[Alon Levy]

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 
> . 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 .
> 
>

Re: [Spice-devel] [xf86-video-qxl] Enable smartcard support for XSpice.

[Alon Levy]

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 .
> 
>>> +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

[Alon Levy]

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"  
> To: "users, apache"  
> 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  
>> 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  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 >>> 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

Re: FlashDevelop for multiple projects

[Alon Levy]

On 11/07/2014 08:43 PM, Héctor A wrote:
> What do you mean by multiple projects? A workspace similar to FB, or having
> a Project referencing other soure paths?

I meant the first option. I also happen to have the second option, but
that is solvable like you mentioned.

>
> For the first, FD doesn't support a workflow similar to that. What you can
> do is enabling multi-instance mode when installing FD and open several
> instances of FD with each Project, personally I like that more than FB
> workspaces, but I agree it has its advantages in some scenarios. Anyway,
> something similar is coming for FD 5.
Can you force rebuilding of app A when library L is updated? (i.e. a new
swc that A references is updated).

>
> For the second, you can add source paths and library references in the
> Project properties.
>
> On Fri, Nov 7, 2014 at 3:27 PM, Alon Levy  wrote:
>
>> 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
>>

FlashDevelop for multiple projects

[Alon Levy]

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

[Alon Levy]

On 10/30/2014 06:39 PM, vtoso...@redhat.com wrote:
> From: Christophe Fergeau 
> 
> 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 
>  #include 
> -#include 
>  #include 
> +#ifdef WITH_GST1AUDIO
> +#include 
> +#else
> +#include 
>  #include 
> +#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

Re: [Spice-devel] [vdagent-linux v2] randr: handle XRRScreenChangeNotifyEvent

[Alon Levy]

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
> mailto:marcandre.lur...@gmail.com>> wrote:
> 
> ping
> 
> 
> On Wed, Aug 27, 2014 at 8:51 PM, Marc-André Lureau
> mailto:marcandre.lur...@redhat.com>>
> wrote:
> 
> From: Marc-Andre Lureau  >
> 
> 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)
>  {
>  

Re: [Spice-devel] Fwd: a question about Xspice

[Alon Levy]

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 
> 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

[Alon Levy]

On 10/19/2014 05:12 AM, Ray Strode wrote:
> From: Ray Strode 
> 
> 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 

> 
> Signed-off-by: Ray Strode 
> ---
>  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 = 

Re: [Spice-devel] unwatchable choppy performance using fullscreen flash in windows VM

[Alon Levy]

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,

> 
> 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

[Alon Levy]

On 10/12/2014 03:24 PM, Marc-André Lureau wrote:
> From: Marc-Andre Lureau 
> 
> 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

[Alon Levy]

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?

[Alon Levy]

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

[Alon Levy]

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] failed to initialize directx in w7

[Alon Levy]

On 08/21/2014 04:48 AM, arnaud gaboury wrote:
> I am not sure this issue is tight to Red Hat qxl GPU driver, but I
> can't initialize directxX on a guest windows 7.
> 
> Trying to start a game, I get the merror message :
> Failed to initialize directX
> 
> Of course, directX is installed on the w7 guest, and properly.
> The dxdiag command, a directx diagnostic tool, does not show any error.
> Some summary under the video :
> 
> Driver name : Red Hat QXL GPU
> Processor type : SeaBIOS VBEC(C) 2011
> 
> No Directx functionality are available (Direct Draw, Direct3D, AGP texture)
> 
> I am not a windows expert, but I would like to know if DirectX is
> compatible with QXL driver.

No it isn't. There is no support for it in our drivers.

> If not, what is the process to be able to run directX on the windows
> guest ? If both are compatible, what did I miss ? The VM is working
> perfectly with virtio & qxl.
> Please find below my virt-install command:

This won't help since it's a driver problem.

> -
> virt-install --connect qemu:///system --name=tintinWinoz --memory 4096
> --cpu host-model-only --os-variant=win7 --disk /myVM/tintin --boot
> cdrom,hd --virt-type kvm --graphics spice --controller
> scsi,model=virtio-scsi --cdrom /dev/cdrom --disk
> /drawer/myIso/w7.iso,device=cdrom
> -
> 
> I thereafter installed manually from the w7 guest virtio & qxl drivers.
> 
> Thank you for advices.
> ___
> 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.

[Alon Levy]

On August 22, 2014 9:16:31 AM EDT, Jeremy White  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] [PATCH] [xf86-video-qxl] In XSpice mode, enable the ability to specify the various ram buffer sizes.

[Alon Levy]

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  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"
>>  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.

[Alon Levy]

With agent running we do.

On August 22, 2014 7:55:19 AM EDT, "Marc-André Lureau"  
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 
>> ---
>>  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_MOD

Re: [Spice-devel] [PATCH xf86-qxl] drm: fail gracefuly on monitor resize

[Alon Levy]

On 08/08/2014 08:35 PM, Marc-André Lureau wrote:
> If drmModeSetCrtc() failed, try to fallback to previous working
> configuration.

ACK

> 
> Related to:
> https://bugzilla.redhat.com/show_bug.cgi?id=1127552
> ---
>  src/qxl_drmmode.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/src/qxl_drmmode.c b/src/qxl_drmmode.c
> index f9eca5f..42347e6 100644
> --- a/src/qxl_drmmode.c
> +++ b/src/qxl_drmmode.c
> @@ -214,11 +214,13 @@ drmmode_set_mode_major(xf86CrtcPtr crtc, DisplayModePtr 
> mode,
>   }
>   ret = drmModeSetCrtc(drmmode->fd, 
> drmmode_crtc->mode_crtc->crtc_id,
>fb_id, x, y, output_ids, output_count, 
> &kmode);
> - if (ret)
> + if (ret) {
>   xf86DrvMsg(crtc->scrn->scrnIndex, X_ERROR,
>  "failed to set mode: %s", strerror(-ret));
> - else
> + return FALSE;
> + } else {
>   ret = TRUE;
> + }
>  
>   if (crtc->scrn->pScreen)
>   xf86CrtcSetScreenSubpixelOrder(crtc->scrn->pScreen);
> @@ -825,8 +827,9 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width, int 
> height)
>   xf86CrtcPtr crtc = xf86_config->crtc[i];
>   if (!crtc->enabled)
>   continue;
> - drmmode_set_mode_major(crtc, &crtc->mode, crtc->rotation,
> -crtc->x, crtc->y);
> + if (!drmmode_set_mode_major(crtc, &crtc->mode, crtc->rotation,
> +crtc->x, crtc->y))
> +goto fail;
>   }
>  
>   {
> 

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] Questions on usbredir + XSpice

[Alon Levy]

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

[Alon Levy]

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] Help with SmartCards and XSpice

[Alon Levy]

On 08/05/2014 05:33 PM, Jeremy White wrote:
> Thanks!
> 
> I'm going to mostly repeat what I think you just said to make sure I
> understand you; please correct me if I get it wrong.
> 
>> 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
> 
> Ah, okay; so Spice just relays bits from libcacard, it doesn't interpret
> them in any way.  Makes sense.
> 
>>
>> 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
> 
> Okay, I think that lines up with some further research I did.  That is,
> it seems like a good approach appears to be to write a driver to
> interface with pcsc-lite (e.g. a bundle to go into
> /usr/lib64/pcsc/drivers).  I think that would then make the flow
> something like this:
> 
>   client hardware <--> spice-gtk  (using libcacard library)
>   spice-gtk <--> spice-server (spice protocol)
>   spice-server <-->  new spiceccid module
> (unknown protocol, probably libcacard influenced)
>   spiceccid <--> pcsc-lite.so (driver/bundle interface)
>   pcsc-lite then connects to applications (e.g. pam) as usual
> 
> That seem about right?
> 
>> 2. new protocol - I guess you ruled that out already.
> 
> I didn't even consider it; I just imagined that reusing the existing
> channels was the smart approach.  Did I miss a better path by thinking
> inside the box?

I don't know - I haven't considered it in any amount of detail, I was
just pointing out the obvious I guess, sorry. I meant simply that if
your aim was (which clearly it isn't now) to abstract at the
PAM/Credential (might not be the same thing) level you could tailor a
protocol for that.

> 
>> 3. pam modlue consuming APDUs from card - what you proposed - same as 1
>> but using a pam module to consume the APDUs.
> 
> Yeah, I think approach #1 is better.
> 
> In fact, it looks like we could hook at many points in the stack; we
> could hook at the pam level, at the coolkey level, the pcsc-lite level,
> and potentially even at the ccid level (e.g. below ccid).  But my (still
> naive and limited) instincts suggest that we want a peer to the ccid
> module, which is what I understand #1 to be.
> 
> 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).

> 
> 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

[Alon Levy]

On 08/06/2014 02:02 PM, Hans de Goede wrote:
> Hi,
> 
> On 08/06/2014 08:02 AM, Alon Levy wrote:
>> On 08/05/2014 10:52 PM, Jeremy White wrote:
>>> While I'm researching, I thought I'd look into the next challenge for
>>> XSpice - usb device redirection.
>>>
>>> It faces similar challenges to the CAC card stuff.  That is, my sense is
>>> that the usbredir library and utility set is all about reading client
>>> machine USB device information and relaying it through to qemu, which
>>> then exposes it as a 'real' device to the guest OS.
>>>
>>> Again, with XSpice, we don't have qemu :-(.
>>>
>>> Ideally, we'd find some mechanism to inject a usb device into the system
>>> running XSpice.
>>>
>>> I've done some further research, and the usbip project would seem
>>> useful.  It was here:
>>>http://usbip.sourceforge.net/
>>> but apparently is now in the kernel.
>>>
>>> If we use that, then the challenge would appear to be translating the
>>> protocols.
>>>
>>> Alternates:
>>>   1.  Use usbip end-to-end
>>>I'd like to avoid this; there are benefits to having all spice
>>> traffic go over the same channel
>>>   2.  ???  Insight appreciated  ???
>>>   (I can't help but feel there are other methods for simulating a
>>> USB device, but I'm fairly ignorant of this space).
>>>
>>
>> 2. Teach usbredir to use a kernel without a vm.
> 
> Yes that would be the rigt solution to this, there are use-cases outside
> of Xspice for this too. The solution you're looking for here is to
> wtite a virtual hcd device (driver) for the kernel talking the

So something like http://sourceforge.net/projects/usb-vhci/ ?

Or if that is a bad starting point, which one is?
ehci-hcd.c / ohci-hcd.c / other? (looking at kernel/drivers/usb/host)

> usbredir protocol, so basically do what the server side usbip bits
> do, but then with a new protocol.
> 
> I would advice against going for a protocol translater, your time would
> better spend on doing this properly right away.
> 
> I would certsainly be interested in testing and reviewing patches
> for this and help getting them added to the upstream kernel.
> 
> Regards,
> 
> Hans
> 

___
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

[Alon Levy]

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] Questions on usbredir + XSpice

[Alon Levy]

On 08/05/2014 10:52 PM, Jeremy White wrote:
> While I'm researching, I thought I'd look into the next challenge for
> XSpice - usb device redirection.
> 
> It faces similar challenges to the CAC card stuff.  That is, my sense is
> that the usbredir library and utility set is all about reading client
> machine USB device information and relaying it through to qemu, which
> then exposes it as a 'real' device to the guest OS.
> 
> Again, with XSpice, we don't have qemu :-(.
> 
> Ideally, we'd find some mechanism to inject a usb device into the system
> running XSpice.
> 
> I've done some further research, and the usbip project would seem
> useful.  It was here:
>http://usbip.sourceforge.net/
> but apparently is now in the kernel.
> 
> If we use that, then the challenge would appear to be translating the
> protocols.
> 
> Alternates:
>   1.  Use usbip end-to-end
>I'd like to avoid this; there are benefits to having all spice
> traffic go over the same channel
>   2.  ???  Insight appreciated  ???
>   (I can't help but feel there are other methods for simulating a
> USB device, but I'm fairly ignorant of this space).
> 

2. Teach usbredir to use a kernel without a vm.

Hans, can you help?

> 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] Help with SmartCards and XSpice

[Alon Levy]

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 1/7] gallium/u_math.h: don't redefine INFINITY and NAN in VS2013

[Alon Levy]

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

Re: [Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp

[Alon Levy]

On 07/24/2014 02:12 PM, Alon Levy wrote:
> From: Alon Levy 
> 
> Fixed build error at glsl_parser.yy for Visual Studio 2013
> 
> Signed-off-by: Alon Levy 

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 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead

[Alon Levy]

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  
>> 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 
>>>>> ---
>>>>>  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 
>>>>>  #include 
>>>>>
>>>>> +#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: [Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp

[Alon Levy]

On 07/24/2014 02:12 PM, Alon Levy wrote:
> From: Alon Levy 

Forgot to add Ian as cc.

> 
> Fixed build error at glsl_parser.yy for Visual Studio 2013
> 
> Signed-off-by: Alon Levy 
> ---
> 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: [Spice-devel] [PATCH] Release 0.1.2

[Alon Levy]

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

Re: [Spice-devel] [PATCH] Release 0.1.2

[Alon Levy]

> 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

[Mesa-dev] [PATCH] mesa/imports.h: VS2013 doesn't provide strcasecmp

[Alon Levy]

From: Alon Levy 

Fixed build error at glsl_parser.yy for Visual Studio 2013

Signed-off-by: Alon Levy 
---
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

[ANNOUNCE] xf86-video-qxl 0.1.2

[Alon Levy]

-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

[ANNOUNCE] xf86-video-qxl 0.1.2

[Alon Levy]

-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

[Spice-devel] [ANNOUNCE] xf86-video-qxl 0.1.2

[Alon Levy]

-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

[Spice-devel] [PATCH] Release 0.1.2

[Alon Levy]

Signed-off-by: Alon Levy 
---
 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

[Mesa-dev] [PATCH 7/7] mesa/shaderimage.c: fix inconsistent sign warning

[Alon Levy]

Signed-off-by: Alon Levy 
---
 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

[Mesa-dev] [PATCH 5/7] wgl: stw_pixelformat_get_info: correct type for index variable

[Alon Levy]

Signed-off-by: Alon Levy 
---
 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 6/7] glsl: fix inconsistent struct/class warning in vs12

[Alon Levy]

Remove incorrect struct prefix, ir_variable is a class

Signed-off-by: Alon Levy 
---
 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 1/7] gallium/u_math.h: don't redefine INFINITY and NAN in VS2013

[Alon Levy]

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 3/7] gallium/u_debug_flush.c: fix build error for vs12

[Alon Levy]

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 
---
 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 
 
@@ -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

[Alon Levy]

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 4/7] u_math.h: fix 64 to 32 bit truncation warning

[Alon Levy]

Signed-off-by: Alon Levy 
---
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 2/7] glsl/glsl_parser.yy: vs12 doesn't have strcasecmp, use _stricmp instead

[Alon Levy]

Signed-off-by: Alon Levy 
---
 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 
 #include 
 
+#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

Re: [Spice-devel] server down?

[Alon Levy]

> It seems like all the content on the "spice-space" site is unavailable. Has
> it moved somewhere else?

Seems to be ok right now.

> 
> Regards,
> 
> Matt Elliott
> Email: matt.elli...@telvent.com
> 
> ***Internet Email Confidentiality Footer*
> 
> This email and any files transmitted with it are confidential and intended
> solely for the use of the organization or individual to whom they are
> addressed. It is expressly forbidden to retransmit or copy email and/or this
> attached files without our permission. If you are not the addressee
> indicated in this message (or responsible for delivery of the message to
> such person), you may not copy or deliver this message to anyone. In such
> case, you should destroy this message and kindly notify the sender by reply
> email. Please advise immediately if you or your employer does not consent to
> Internet email for messages of this kind. Opinions, conclusions and other
> information in this message that do not relate to the official business of
> my firm shall be understood as neither given nor endorsed by it.
> 
> ** Confidencialidad de Correo electr�nico de Internet **
> 
> Este correo electr�nico y cualquier archivo transmitido con el, es
> confidencial y destinado exclusivamente para el empleo de la organizaci�n o
> el individuo a quien esta dirigido. Esta expresamente prohibido su reenvio o
> copia del correo electr�nico y/o de los archivos anexados sin permiso del
> remitente. El contenido esta protegido seg�n la regulaci�n sobre la
> Protecci�n de Datos e Informaci�n Personal. Si usted no es el destinatario
> indicado en este mensaje (o responsable de la entrega del mensaje a tal
> persona), no puede copiar, reenviar o entregar este mensaje. En tal caso,
> usted debe destruir este mensaje y notificar al remitente por el correo
> electr�nico de respuesta. Puede notificar igualmente si no desea recibir
> correos electr�nicos de esta clase. Las opiniones, conclusiones y otra
> informaci�n en este mensaje que no se relaciona con la actividad de la
> compa��a ni ser�n entendidas como autorizadas por �sta.
> 
> ___
> 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

[Alon Levy]

> 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*)×tamp, 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] [vdagent-linux 2/2] Handle STRING selection type

[Alon Levy]

> 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] Setting colour depths

[Alon Levy]

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] 
> 
> 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 (v2)] Make sure the child is able to connect to the X server before exiting the mainline.

[Alon Levy]

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 
> ---

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 
>  #include 
>  #include 
> +#include 
>  
>  #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

[Alon Levy]

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.

[Alon Levy]

On 06/24/2014 12:05 AM, Jeremy White wrote:
> 

ACK

> Signed-off-by: Jeremy White 
> ---
>  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)
>  "  -uset 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 win-vdagent] Don't refresh displays config when updating

[Alon Levy]

On 06/19/2014 08:20 PM, Marc-André Lureau wrote:
> wnd_proc() is called during ChangeDisplaySettings(), when handling
> monitors config. However, calling get_displays() will overwrite the
> desired config.
> 
> So, while updating from 1 to 4 enabled monitors, when the 2nd monitor
> config is enabled, the current config is read, and overwrite the rest of
> the config, so first time only 2nd monitor is enabled, second time, 3rd
> monitor etc.
> 

ACK

nice comment ;)

> https://bugzilla.redhat.com/show_bug.cgi?id=144
> ---
>  vdagent/vdagent.cpp | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/vdagent/vdagent.cpp b/vdagent/vdagent.cpp
> index 15216d9..aa44383 100644
> --- a/vdagent/vdagent.cpp
> +++ b/vdagent/vdagent.cpp
> @@ -148,6 +148,7 @@ private:
>  bool _running;
>  bool _desktop_switch;
>  DesktopLayout* _desktop_layout;
> +bool _updating_display_config;
>  DisplaySetting _display_setting;
>  FileXfer _file_xfer;
>  HANDLE _vio_serial;
> @@ -615,11 +616,14 @@ bool VDAgent::handle_mouse_event(VDAgentMouseState* 
> state)
>  
>  bool VDAgent::handle_mon_config(VDAgentMonitorsConfig* mon_config, uint32_t 
> port)
>  {
> +VDAgent* a = _singleton;
>  VDIChunk* reply_chunk;
>  VDAgentMessage* reply_msg;
>  VDAgentReply* reply;
>  size_t display_count;
>  
> +a->_updating_display_config = true;
> +
>  display_count = _desktop_layout->get_display_count();
>  for (uint32_t i = 0; i < display_count; i++) {
>  DisplayMode* mode = _desktop_layout->get_display(i);
> @@ -649,6 +653,10 @@ bool VDAgent::handle_mon_config(VDAgentMonitorsConfig* 
> mon_config, uint32_t port
>  _desktop_layout->set_displays();
>  }
>  
> +a->_updating_display_config = false;
> +/* refresh again, in case something else changed */
> +a->_desktop_layout->get_displays();
> +
>  DWORD msg_size = VD_MESSAGE_HEADER_SIZE + sizeof(VDAgentReply);
>  reply_chunk = new_chunk(msg_size);
>  if (!reply_chunk) {
> @@ -1439,7 +1447,8 @@ LRESULT CALLBACK VDAgent::wnd_proc(HWND hwnd, UINT 
> message, WPARAM wparam, LPARA
>  vd_printf("Display change");
>  // the desktop layout needs to be updated for the mouse
>  // position to be scaled correctly
> -a->_desktop_layout->get_displays();
> +if (!a->_updating_display_config)
> +a->_desktop_layout->get_displays();
>  break;
>  case WM_TIMER:
>  a->send_input();
> 

___
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.

[Alon Levy]

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 
> ---
>  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 
>  #include 
>  #include 
> +#include 
>  
>  #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.

[Alon Levy]

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 
> ---
>  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 
>  #include 
>  #include 
> +#include 
>  
>  #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] [vdagentd] Add an explicit switch to signal fake uinput devices.

[Alon Levy]

On 06/23/2014 11:41 PM, Jeremy White wrote:
> 

ACK

> Signed-off-by: Jeremy White 
> ---
>  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   set virtio serial port  [%s]\n"
>  "  -S   set udcs socket [%s]\n"
>  "  -uset 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] [PATCH xf86-qxl] drm: restore cursor after resolution change

[Alon Levy]

On 07/02/2014 01:22 PM, Marc-André Lureau wrote:
> From: Marc-André Lureau 
> 
> 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

[Spice-devel] [PATCH] qxl_image.c: fix compilation break

[Alon Levy]

Since 3d511c30206bd8c9a207c436186a03af0bb02962 Xspice building is broken
due to undefined MAX_RELOCS when not building with XF86DRM_MODE.
---
 src/qxl_image.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/qxl_image.c b/src/qxl_image.c
index eb66b63..8927fd4 100644
--- a/src/qxl_image.c
+++ b/src/qxl_image.c
@@ -159,6 +159,7 @@ qxl_image_create (qxl_screen_t *qxl, const uint8_t *data,
 
chunk_size = MAX (512 * 512, dest_stride);
 
+#ifdef XF86DRM_MODE
/* ensure we will not create too many pieces and overflow
 * the command buffer (MAX_RELOCS).  if so, increase the chunk_size.
 * each loop creates at least 2 cmd buffer entries, and
@@ -170,6 +171,7 @@ qxl_image_create (qxl_screen_t *qxl, const uint8_t *data,
ErrorF ("adjusted chunk_size to %d\n", chunk_size);
 #endif
}
+#endif
 
while (h)
{
-- 
1.9.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] qxl_driver.c: fix compiler warning 'defined but not used' qxl_kernel_mode_enabled

[Alon Levy]

> On Mon, Jun 09, 2014 at 04:08:37PM +0300, Alon Levy wrote:
> > Signed-off-by: Alon Levy 
> > ---
> >  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

Re: [Qemu-devel] [PATCH] ccid-card-emulated: use EventNotifier

[Alon Levy]

> Shut up Coverity's complaint about unchecked fcntl return values,
> and especially make the code simpler and more efficient.
> 
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Alon Levy 

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

[Alon Levy]

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:
> 
> 
>   
> 
> 
>   
> 
> 
>   
> 
> - 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

[Alon Levy]

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] [PATCH 0/2] stability for dual head

[Alon Levy]

On 06/09/2014 04:18 PM, David Mansfield wrote:
> 
> On 06/09/2014 07:18 AM, Alon Levy wrote:
>> On 06/03/2014 04:14 PM, David Mansfield wrote:
>>> Bump. I'll make it easy.  This is a multiple choice response form.
>>> Anyone reading this can respond with one letter so save time and effort.
>>>
>>> a) "We're too busy with RHEL 7/paying clients, come back in a month/some
>>> timeframe"
>>> b) "There's an SEP field on these problems, everyone who understands
>>> that code has moved on"
>>> c) "Go away"
>>> d) "Oops, I've been meaning to get back to you but I keep forgetting and
>>> life is hectic..."
>>> e) "Didn't you hear? SPICE is dead."
>>> f) "Other." Please elaborate using the space provided below:
>> The first patch looks good (just adjusting the #if to disable the
>> print). I'll pick it up, thanks, you deserved a faster response.
>>
>> No idea what SEP is.
> 
> Hi Alon,
> 
> I followed Marc-André's advice and sent these out to DRI ond xorg
> mailing lists, respectively.  The qxl.ko patch was picked up by Dave
> Airlie and committed to drm-next branch.
> 
> The second is still without a home.
> 
> (BTW: An SEP is a "somebody else's problem" effect, see
> http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem, popularized in
> Douglas Adams' Hitchhiker's Guide novel.  Very funny concept.)

Missed that.

> 
> Any possibility of help with issue #2, the xorg-devel list is silent on
> this  one and I don't know who the maintainer is specifically. Without
> this patch xorg-qxl is trivially crashable when using dual head at
> 1920x1200 resolution (or potentially lower resolution).
> 

96 relocs with 512x512 chunks - what do you do to crash it?

Soren Sandmann is the maintainer, but I did a release once, I can commit
it once I'm done testing (need to allow large resolutions which by
default are limited to surface0_area_size).
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH] qxl_driver.c: fix compiler warning 'defined but not used' qxl_kernel_mode_enabled

[Alon Levy]

Signed-off-by: Alon Levy 
---
 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

[Spice-devel] [PATCH] qxl_kms: read virtual monitor size from xorg.conf

[Alon Levy]

Signed-off-by: Alon Levy 
---
 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

Re: [Spice-devel] [PATCH spice-protocol] RFC: Add VD_AGENT_CAP_ANY_SELECTION_TYPE

[Alon Levy]

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 
>>>
>>> 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

Re: [Spice-devel] [PATCH 0/2] stability for dual head

[Alon Levy]

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

[Alon Levy]

On 06/04/2014 07:45 PM, Marc-André Lureau wrote:
> From: Marc-André Lureau 
> 
> 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] how to read the spice-server source code?

[Alon Levy]

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: [Qemu-devel] [PATCH] libcacard: improve documentation

[Alon Levy]

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 
> Cc: Ray Strode 

Did you mean Robert Relyea  ?

Thanks, looks good.
Reviewed-by: Alon Levy 

> Signed-off-by: Paolo Bonzini 
> ---
>  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  2001
> +on the client run vscclient, built when you built QEMU:
> +
> +vscclient  2001
> +
>  
>  6.

Re: [Qemu-devel] [Qemu-trivial] [PATCH] libcacard: remove useless initializers

[Alon Levy]

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  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

[Alon Levy]

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 

[Spice-devel] glz cleanup

[Alon Levy]

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: g_malloc cleanups

[Alon Levy]

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 

just one comment below.

> 
> Signed-off-by: Michael Tokarev 
> ---
>  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_n

Re: [Qemu-devel] [PATCH] libcacard: remove useless initializers

[Alon Levy]

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 
> ---
>  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)
>  

Re: [Qemu-devel] [PATCH 0/5] glib thread interface and libcacard cleanups

[Alon Levy]

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 
>> Tested-by: Alon Levy 
> 
> 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 
>> 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

[Alon Levy]

  an unrelated-to-glib change which I had to apply to libcacard here was
>  to replace pstrcpy() back to strncpy().  The reverse conversion has been
>  done in the past, this patch reverts it back to usage of strncpy().
> 
>  and we've some tiny OS-compat code added to vscclient.c here.
> 
> - libcacard: actually use symbols file
> 
>  this is the change which started whole series.  This patch makes export
>  list for libcacard.so 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 
Tested-by: Alon Levy 

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 
Date:   Mon May 5 17:41:32 2014 +0300

libcacard: remove unnecessary EOL from debug prints

Signed-off-by: Alon Levy 

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

[Alon Levy]

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 
>> +#include 
>> +
>> +#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
>> +
>> +
>> 

Re: [Spice-devel] [PATCH 05/12] build.bat: fix copy to install dir for amd64

[Alon Levy]

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

Re: [Spice-devel] [PATCH 01/12] Revert "miniport: halve QXL_IO_UPDATE_IRQ calls"

[Alon Levy]

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 
>>
>> 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 02/12] miniport/qxl.inf: simplify by having FeatureScore for everyone

[Alon Levy]

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_1b36&DEV_0100&SUBSYS_11001af4
>  
> -; WinXP x64 and up
> +; x64
>  [q.NTamd64]
>  %RHAT% %QXL% = qxl, PCI\VEN_1b36&DEV_0100&SUBSYS_11001af4
>  
>  ; Vista x86 and up
>  [q.NTx86.6.0]
> -%RHAT% %QXL% = qxl_vista, PCI\VEN_1b36&DEV_0100&SUBSYS_11001af4
> +%RHAT% %QXL% = qxl, PCI\VEN_1b36&DEV_0100&SUBSYS_11001af4
>  
>  ; Vista x64 and up
>  [q.NTamd64.6.0]
> -%RHAT% %QXL% = qxl_vista, PCI\VEN_1b36&DEV_0100&SUBSYS_11001af4
> +%RHAT% %QXL% = qxl, PCI\VEN_1b36&DEV_0100&SUBSYS_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

[Spice-devel] [PATCH 10/12] xddm/display/amd64: implement Save/RestoreFPU & fast_memcpy_*

[Alon Levy]

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
+ 

[Spice-devel] [PATCH 11/12] add benchmarks for memcpy (RtlCopyMemory) vs fast - fast is slower

[Alon Levy]

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 
+#include 
+
+#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;
+  unsigned char *

[Spice-devel] [PATCH 09/12] xddm/display/amd64: implement CheckAndSetSSE2

[Alon Levy]

---
 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 12/12] display: use RtlCopyMemory instead of fast_memcpy_*

[Alon Levy]

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 01/12] Revert "miniport: halve QXL_IO_UPDATE_IRQ calls"

[Alon Levy]

From: Yonit Halperin 

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

[Alon Levy]

---
 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_*)

[Alon Levy]

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 04/12] display\driver.c: remove unused FlotaToFixed

[Alon Levy]

---
 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 03/12] display/res.h: remove whitespace at EOF

[Alon Levy]

---
 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 06/12] build.bat: more verbose build

[Alon Levy]

---
 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

[Alon Levy]

---
 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