> BTW reading patch 1 again, I wonder what exactly it tries to solve, since > currently when using spice with qemu (no experience with x-spice) you can > already set modes > 1024x768 without problems. Alright, I've spent my day relearning this code, and feel I have a better grasp. The issue is primarily this code here: http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/tree/src/qxl_driver.c#n2325 That sets the current virtual x/y to 1024x768, and calls Xorg's code to process the initial configuration. One of the things that code does is read the configured modelines in the supplied xorg.conf file, and finds a mode that fits within that virtual size. However, having had the virtual display set to 1024, that code will apply that as a maximum, and will pick a modeline from the spiceqxl.xorg.conf file that is within 1024x768. You *can* use xrandr to change to a larger resolution later on, but you cannot specify a default starting resolution in the spiceqxl.xorg.conf file. As far as I can tell, virt-viewer usage never uses an xorg.conf file, so you guys never see this problem. You've always got gnome-settings-daemon or someone else resizing displays for you (which does, in fact work). In my humble opinion, the current code attempts to set a default mode of 1024x768 in a crude and incorrect fashion. This led to Marc-André's patch of last July (c1b537fc, Return a preferred mode matching the current mode), which I think in turn triggers bug 894421. The good news is that I ever so humbly <grin> think my patch 1 fixes all of these issues. Essentially, it sets the M_T_PREFERRED flag on a 1024x768 mode in a non invasive way. In my testing, it works correctly for my case, and for the cases I tried with virt viewer and fc18. I was able to reproduce the behavior Marc-André reported last summer, and confirm that my patch seems to also correct for it. I do have some mysteries. fc18 doesn't seem to restore screen resolution after reboot, which surprises me. (This is true both with and without my patch). I also don't understand why I thought my patch 2/2 was needed; I can no longer find any reason for that. My only hunch is that an earlier, more naive version of patch 1 may have required it, and I never realized it could be dropped. I also could not reproduce bug 894421, although without my patch I see a variation of it, where default window sizes are often perversely small. I am resubmitting my patch 1 as a new patch, which partially reverts c1b537fc; I would appreciate it if others could review that code. Cheers, Jeremy _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel