Hi, On 01/28/2013 08:39 PM, Jeremy White wrote:
I've spent more time trying to understand X and the qxl driver in a qemu / 4 head environment. It's a bit challenging; there isn't really definitive documentation for what we can expect ScreenInfoRec records to contain (or even exactly what we're supposed to set and when). Does anyone have a set of tests, formal or informal, that are 'good enough' for testing the qxl driver with qemu? I'd like to feel that I'm putting the code through a known set of tests prior to claiming that my patch is good enough.
What I usually do is fire up a Fedora-18 vm, then add a second and third monitor from view->displays, then resize them a bit, drag windows from one monitor to the other, etc. That is pretty much my "smoke" test I'm afraid we don't have anything better atm :|
Also, I'm troubled by the modes we report back. I see that we report that we support modes up to 2560x1600, which is true - for one head. So a user is permitted to go into gnome settings and set all 4 heads to 2560x1600. (While fails in a lovely way when you go to apply :-/). I *think* that is 'correct' behavior - but I'm not sure.
Yes that is correct behavior, or the best we can do for now at least ...
That is, I think multi head environments have no clean way to report 'in aggregate, these 4 heads can do this many square pixels'. Instead, we always report 'no one head can do more than this', and then trust the user not to overwhelm the ram we have available. The alternate would be to divide our available ram by the number of heads (so we'd have max resolutions in the 1152x852 range).
Right, and reporting 1152x852 as max resolution is not an acceptable solution ... <snip>
p.s. I observe that we have a fuzzy memory constraint as well. That is, a tail -f /var/log/Xorg0.0.log | grep -i 'out of video memory' gives interesting results as you tweak display sizes in various ways. I presume that is also known
It is a known issue, yes, one which is on the list of things to fix ... Regards, Hans _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel