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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel