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: > > <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! Still need to do a release. > > Thanks, > David > > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel