Real cirrus did have 32bpp according to both the reference manual and qemu's emulation of the hardware. The cirrus DRM driver even had the modesetting code for 32bpp but the driver prevented the creation of 32bpp framebuffers. <br><br>Best,<br>Zach<br><br><div class="gmail_quote">On Mon, Oct 27, 2014, 08:30 Gerd Hoffmann <<a href="mailto:kraxel@redhat.com">kraxel@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mo, 2014-10-27 at 11:00 -0400, Adam Jackson wrote:<br>
> On Fri, 2014-10-24 at 18:31 -0700, Stéphane Marchesin wrote:<br>
><br>
> > Dave, Adam: are you ok with this patch?<br>
><br>
> Seems like it doesn't go far enough?  You'd already need an "aware"<br>
> guest to have this work, since the chip actually being emulated didn't<br>
> have 32bpp.  The pitch check would prevent 1024x768x32 and larger from<br>
> working, which makes it sort of a weak win on its own.<br>
><br>
> Could we read the BAR size from the device instead of hardcoding 4M?<br>
> That alone would make 1920x1200x16 work; and then, if that pitch limit<br>
> isn't encoded into the register space representation, the aware guest<br>
> would have resolutions worth using at least be possible.<br>
<br>
How about stop using cirrus and go for 'qemu -vga std' instead?<br>
<br>
Linux kernel 3.14+ comes with a modesetting driver for the qemu standard<br>
vga (CONFIG_DRM_BOCHS).  Just switch over, and all your cirrus pain is<br>
gone.<br>
<br>
That is much better than trying use features the real cirrus hardware<br>
never had, then praying that all qemu versions in the wild are actually<br>
doing what you want qemu do.<br>
<br>
cheers,<br>
  Gerd<br>
<br>
<a href="https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/" target="_blank">https://www.kraxel.org/blog/<u></u>2014/10/qemu-using-cirrus-<u></u>considered-harmful/</a><br>
<br>
</blockquote></div>