x fails to startup in qemu - no driver for Cirrus card

Having the same problem here using Alpha 5.

By the way, this can be worked around by passing -std-vga to qemu.

confirm with hardy a6

>> By the way, this can be worked around by passing -std-vga to qemu.

Thats true. However there is at least one qemu-launcher-frontend - qtemu - which offers no choice to select the standard vesa card instead of the cirrus card.

Hi,

I'm marking this bug as invalid for xsever-xorg-video-cirrus.
Ratiionale:
I'm working on FAUmachine (www.faumachine.org), which is based partially on qemu (and this is valid for the video card as well, and it shows the same problem).
I've looked through the debdiff from gutsy->hardy, which didn't show anything besides PCI ids relevant for the emulated cirrus card. I believe, these are right in
qemu as well. So it shouldn't be a problem for xserver-xorg-vide-cirrus (but maybe a problem in some other X component).

My best guess, from looking at logs (of FAUmachine) so far is, that some other X component decided (not sure which one) to check for the monitor via calls to the video card and if that fails use a failsafe configuration for the monitor, which in turn won't yield valid modes for the cirrus card. That's however just a guess.
This guess is based on logs I've seen from FAUmachine, which say that the cirrus card is getting probed for DDC requests (which is not implemented yet, either in FAUmachine nor in qemu afaik), so these fail and don't return the right data.

HTH,
   Stefan.

This might also give some clue on why it worked with gutsy, and why it doesn't work in hardy:
"(II) CIRRUS(0): Creating default Display subsection in Screen section
 "Default Screen" for depth/fbbpp 24/32
(==) CIRRUS(0): Depth 24, (==) framebuffer bpp 32"

in gutsy, the framebuffer was still with 24 bits.

My guess what's going on there is the following:
xserver-xorg-video-cirrus will do in src/alp_driver.c an initialisation (function AlpPreInit). In there (somewhere around line 960) the maximum dot clock frequency gets set, depending on the bits per pixel (these seem to come from the framebuffer bpp?). For the gd5446 that's 0 though (line 146), as it doesn't support that 32bpp.

This still doesn't give much clue of *where* this comes from though.

Confirming this bug, thanks to Stefan for the analysis!

bryce, soeren, kees just told me that you have been working on this bug. I tried it out with the release hardy iso image on my laptop, and can still reproduce it. Can you please recheck?

additional information: Kees stated that adding HorizSync and VertRefresh lines works around the bug.

more info: kvm does indeed work, because there's a quirk in dexconf to detect if run under kvm.

I've tested this right now with FAUmachine, and there it is enough to add only DefaultDepth 24 to the xorg.conf.

My best guess is, that this is indeed a X problem, which results from the default depth being 32. Since a real cirrus gd5446 doesn't support this depth, I believe that X wouldn't start with a real card as well.

setting xserver-xorg-video-cirrus task back to new again. I somehow believe that the error is there.

More precise: I think that
src/alp_driver.c:952
       switch(pScrn->bitsPerPixel) {
should be
       switch(pScrn->depth) {

but I must admit, that I don't have too much clue about X in general.

Aha, looking at the new xserver-xorg-video-cirrus driver (1.2.1-1) gives more clue, since it indeed contains a quirk at the second place, which might be responsible:

alp_driver.c:602 contains now:
 /* 32bpp only works on 5480 and 7548 */
 depth_flags = Support24bppFb;
 if (pCir->Chipset == PCI_CHIP_GD5480 || pCir->Chipset ==PCI_CHIP_GD7548)
     depth_flags |= Support32bppFb |
      SupportConvert32to24 |
      PreferConvert32to24;
 /*
  * The first thing we should figure out is the depth, bpp, etc.
  * We support both 24bpp and 32bpp layouts, so indicate that.
  */
 if (!xf86SetDepthBpp(pScrn, 0, 0, 24, depth_flags)) {
  return FALSE;

instead of:
 /*
  * The first thing we should figure out is the depth, bpp, etc.
  * We support both 24bpp and 32bpp layouts, so indicate that.
  */
 if (!xf86SetDepthBpp(pScrn, 0, 0, 0, Support24bppFb | Support32bppFb |
    SupportConvert32to24 | PreferConvert32to24)) {
  return FALSE;

I'll try tomorrow, if this works.

this is indeed a bug in the driver, not in qemu. I'll attach a debdiff in a minute.

... and not in qemu.

in case someone else wants to test, and doesn't want to fiddle with rebuilding the binary first, here's one.

already fixed in intrepid with 1.2.1.

milestoning the bug, I'm currently testing the diff in qemu (non-kvm!)

I'm happy to confirm that the patch indeed fixes the bug. I'm attaching an X.org log with a package build included sistpoty's patch for reference.

Great work, Stefan! :-)

Accepted into -proposed, please test and give feedback here

Possibly with this fix, some portion of the kvm-specific changes to dexconf could be dropped.

If anyone is interested in assisting with this, please file a new bug assigned to me, attach a minimal xorg.conf that has been adequately tested. Here are the current kvm-specific things dexconf is doing:
a) hardcoding the driver to cirrus
b) specifying the depth
c) setting the HorizSync and VertRefresh
d) specifying the available resolutions

In theory, none of these four things should be necessary, but I suspect this bug fix only addresses b and maybe c. Please test if these can be removed and if so, file a bug and I can take care of dropping them in dexconf. Thanks ahead of time.

I've filed bug 237164 for dexconf. Let's continue the discussion about it there.

Hi Reinhard,

Reinhard Tartler [2008-06-03 14:27 -0000]:
> I'm happy to confirm that the patch indeed fixes the bug. I'm attaching
> an X.org log with a package build included sistpoty's patch for
> reference.

Great, thanks for testing! Do you have the time to do the test with
the actual .debs from -proposed again, to verify the actual packages?
Thanks!

just tested the package from -proposed on FAUmachine, works like a charm :).

Copied to hardy-updates.