[Spice-devel] qemu qxl driver and default display size questions

[Hans de Goede]

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