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

[David Mansfield]

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, but here's my environment 
where I can 100% reproduce this issue:

- F20 host ,F20 guest, F20 client (all same box)
- In the libvirt domain xml, a few tweks to increase memory available to 
qxl video framebuffer from 16mb to 32mb in domain xml:

     <video>
       <model type='qxl' ram='131072' vram='131072' heads='1'/>
     </video>

   <qemu:commandline>
     <qemu:arg value='-global'/>
     <qemu:arg value='qxl-vga.vgamem_mb=32'/>
   </qemu:commandline>

- run MATE desktop in guest, not sure if this is necessary or not, but 
it's what I use
- use two (virtual and physical) monitors with 1920x1200 resolution (24 
bit color depth). You will need either a patched kernel (or a 3.16 
kernel), or a patched remote-viewer because of a different bug which is 
fixed in qxl.ko in latest kernel or else the second monitor may show 
"entire" framebuffer instead of monitor 2 area.

At this point "shutter" will crash the system when doing a screenshot 
using the "selection" feature, as will opening the second virtual 
monitor with the saved monitor configuration in .config/monitors.xml.

I appreciate your help getting this in!

Thanks,
David