Red Hat Bugzilla – Bug 383891
Mode selection doesn't take into account color depth
Last modified: 2008-02-12 09:54:53 EST
Description of problem:After upgrading from F7 to F8 I needed to manually create an xorg.conf file because a mode was being chosen that would not work at the default depth of 24. I used systme-config-display to create a generic xorg.conf with depth set to 16 and then I could use X again and more easily adjust the configuration.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual results:Garbage displayed on screen, which eventually locked me out of the machine. I could switch to a VT as long as I didn't wait too long.
Expected results:Normal X display.
Created attachment 259401 [details]
This is from a successful X start up, but does provide information about my
hardware. I don't really think it is a hardware specific problem though. Modes
are limited not only by monitors and DACs, but also by memory and higher color
depths need more memory for the same resolution.
We do filter modes out by available memory. You can even see it in that log:
(II) NV(0): Not using default mode "1792x1344" (insufficient memory for mode)
And you've got plenty enough memory for 1024x768 at 32bpp.
Can you attach a log from an unsuccessful 32bpp run?
Created attachment 283331 [details]
Xorg.0.log from problematic try
I removed my xorg.conf file and rebooted and X did not run properly. I
restarted a few times with mashups of my normal background image and some text
displayed in smaller than normal fonts. Eventually the screen would end up
being vertical bars of various colors, in particular ones appearing in my
background image. When it got to that point c-a-f1 and c-a-bs would not work
and I needed to reboot.
Doing a telinit 3 after the first try or two let me get at things.
I'll also attach an Xorg.0.log from when I use my xorg.conf file that gets
things to work.
Created attachment 283341 [details]
xorg.conf I normally use
Created attachment 283351 [details]
Xorg.0.log using my normal xorg.conf file
1920x1080 at 32bpp just _barely_ fits into vram on that card. It's also a
completely stupid choice of resolution for that monitor, but that's a different
I suspect what's happening here is the card's getting starved. You're probably
burning all your memory bandwidth just scanning the picture out, and eventually
the DMA engine just gives up. Does 1600x1200 work reliably?
1600x1200 at 24 bit color depth (which I think effectively uses 32) seems to
I built an nv driver that I think will fix this into rawhide. Can you test
that, or do you need an F8 build?
As it happens I am trying to do a yum upgrade of that machine to Rawhide now.
I think I have the dependency issues worked around for now, and I should be able
to confirm that I want to proceed in a couple of minutes. Then if things work
well the machine will be running rawhide when I get in tomorrow and I can retest
this. If things don't work it may be another day or two. But I don't think you
should need to bother with an f8 version.
The upgrade attempt last night got screwed up when I had the I/O lockup problem
occur (this is one of the things I hoping gets fixed with the upgrade) after the
start of actual updates from the yum upgrade and left things a bit messed up.
So it will be another day or two before I can give you feedback.
I was able to test this with rawhide (xorg-x11-drv-nv-2.1.6-7.fc9) and it seems
to work reasonably. When I booted without an /etc/x11/xorg.conf file and logged
in I got 1600x1200 at 85Hz (according to prefernces, but that preference seemed
believable). So I think the problem is fixed in Rawhide.
Cool. Marking fixed, will push as an F8 update too.