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

[David Mansfield]

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?
Note each pass requires two relocs (and most call sites require at least 
one slot for themselves, too).  So we have a maximum image size (at full 
DE width of 3840 pixels):

(96/2) * 512 * 512 / 4 / 3840 = 819 pixels high.  And mine is 1200 
pixels high.  So anything updating the entire 3840x1200 at once will 
crash.  See below:

>
> 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).
So there are two "easy" ways to crash.  Both involve 1920x1200 dual 
head, which means (for me) editing the domain.xml:

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

After this, I can crash if I launch "shutter" screenshot program, and 
click the "Selection" button.  This button "grays out" the entire 
desktop and at this point it often crashes.  If not the very first time 
then the second or third. Just keep clicking and pressing ESC and it'll 
crash for sure.

NOTE: my environment is F20 guest, host and client - all on the same box.

The other way is: after you set up dual head 1920x1200 then logout, 
shutdown (maybe not necessary), close remote-viewer then login again, 
and re-activate the second monitory window.  As soon as the second 
monitor window is activated, gsd or something automatically "remembers" 
that both monitors should be 1920x1200, instead of 1024x768 or whatever, 
and crashes.  It is customary practice here to remove 
~/.config/monitors.xml before logging in to prevent this crash, because 
then the automatic re-sizing doesn't occur.

This is with MATE (or xfce) desktop.  Not sure about GNOME3 which 
re-orders the ioctl a bit and you may get lucky.

NOTE2: To get dual head working properly for non-gnome3 you need the 
qxl.ko patch OR a patch to remote-viewer I sent out a while back or else 
the second monitor won't work properly.

Thanks,
David