Bug 383891 - Mode selection doesn't take into account color depth
Mode selection doesn't take into account color depth
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
i686 Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-14 22:59 EST by Bruno Wolff III
Modified: 2008-02-12 09:54 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-12 09:54:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log (54.23 KB, text/plain)
2007-11-14 23:04 EST, Bruno Wolff III
no flags Details
Xorg.0.log from problematic try (62.21 KB, text/plain)
2007-12-10 16:28 EST, Bruno Wolff III
no flags Details
xorg.conf I normally use (988 bytes, text/plain)
2007-12-10 16:32 EST, Bruno Wolff III
no flags Details
Xorg.0.log using my normal xorg.conf file (54.28 KB, text/plain)
2007-12-10 16:33 EST, Bruno Wolff III
no flags Details

  None (edit)
Description Bruno Wolff III 2007-11-14 22:59:52 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):

How reproducible:100%

Steps to Reproduce:
1.remove xorg.conf
2.restart X
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.

Additional info:
Comment 1 Bruno Wolff III 2007-11-14 23:04:36 EST
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.
Comment 2 Adam Jackson 2007-12-10 15:22:27 EST
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?
Comment 3 Bruno Wolff III 2007-12-10 16:28:30 EST
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.
Comment 4 Bruno Wolff III 2007-12-10 16:32:55 EST
Created attachment 283341 [details]
xorg.conf I normally use
Comment 5 Bruno Wolff III 2007-12-10 16:33:58 EST
Created attachment 283351 [details]
Xorg.0.log using my normal xorg.conf file
Comment 6 Adam Jackson 2007-12-12 12:02:51 EST
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?
Comment 7 Bruno Wolff III 2007-12-12 17:38:56 EST
1600x1200 at 24 bit color depth (which I think effectively uses 32) seems to
work OK.
Comment 8 Adam Jackson 2008-01-22 16:18:58 EST
I built an nv driver that I think will fix this into rawhide.  Can you test
that, or do you need an F8 build?
Comment 9 Bruno Wolff III 2008-01-22 18:05:55 EST
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.
Comment 10 Bruno Wolff III 2008-01-23 15:19:50 EST
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.
Comment 11 Bruno Wolff III 2008-01-25 17:19:15 EST
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.
Comment 12 Adam Jackson 2008-02-12 09:54:53 EST
Cool.  Marking fixed, will push as an F8 update too.

Note You need to log in before you can comment on or make changes to this bug.