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. 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. 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). Does anyone know for sure? Cheers, Jeremy 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 and largely understood, but is being exacerbated by the gnome fallback insistence on sending full screen updates so our command pipeline is in a worst case state. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel