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