Bug 383891

Summary: Mode selection doesn't take into account color depth
Product: [Fedora] Fedora Reporter: Bruno Wolff III <bruno>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 8CC: xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-12 14:54:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Xorg.0.log
none
Xorg.0.log from problematic try
none
xorg.conf I normally use
none
Xorg.0.log using my normal xorg.conf file none

Description Bruno Wolff III 2007-11-15 03:59:52 UTC
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):
xorg-x11-server 1.3.0.0-33.fc8

How reproducible:100%


Steps to Reproduce:
1.remove xorg.conf
2.restart X
3.
  
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-15 04:04:36 UTC
Created attachment 259401 [details]
Xorg.0.log

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 20:22:27 UTC
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 21:28:30 UTC
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 21:32:55 UTC
Created attachment 283341 [details]
xorg.conf I normally use

Comment 5 Bruno Wolff III 2007-12-10 21:33:58 UTC
Created attachment 283351 [details]
Xorg.0.log using my normal xorg.conf file

Comment 6 Adam Jackson 2007-12-12 17:02:51 UTC
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
issue.

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 22:38:56 UTC
1600x1200 at 24 bit color depth (which I think effectively uses 32) seems to
work OK.

Comment 8 Adam Jackson 2008-01-22 21:18:58 UTC
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 23:05:55 UTC
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 20:19:50 UTC
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 22:19:15 UTC
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 14:54:53 UTC
Cool.  Marking fixed, will push as an F8 update too.