Description of problem: X doesn't start at all in rawhide with the trident driver: (==) Log file: "/var/log/Xorg.0.log", Time: Sun Mar 9 03:05:59 2008 (EE) Unable to locate/open config file New driver is "trident" (==) Using default built-in configuration (30 lines) (EE) Failed to load module "fbdev" (module does not exist, 0) (EE) TRIDENT(0): No valid modes found (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found giving up. xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): Server error. This appears to be an X wide or kernel problem rather than the trident driver itself as the driver package itself hasn't been updated, and it did work up until recently, but I'm filing it here as I don't know where else it should go. Version-Release number of selected component (if applicable): These are some relevant versions of the kernel and the Xorg server: kernel-2.6.25-0.95.rc4.fc9.i686 xorg-x11-server-Xorg-1.4.99.901-1.20080307.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Update to rawhide 2. Move /etc/X11/xorg.conf aside if there is one there 3. startx Actual results: See attachment Expected results: X should start Additional info: I moved aside the xorg.conf which didn't make any difference. I also tried manually setting it to the vesa driver, but didn't work either.
Created attachment 297352 [details] /var/log/Xorg.0.log
Hmm, it *does* actually appear to be trident-specific. I used the default /etc/X11/xorg.conf created by system-config-display and then modified the driver line to: driver: vesa X starts. What's also odd is that if I moved the xorg.conf completely, system-display-config didn't seem able to automatically fall back to the vesa driver by itself. Cc'ing Dave Airlie who fixed the trident driver when it wasn't working in an earlier rawhide (bug #433254).
Created attachment 297737 [details] Working /etc/X11/xorg.conf This xorg.conf works. To generate this I ran "system-config-display", then changed the Driver in "Device" section from "trident" to "vesa". To reproduce bug, simply rename "vesa" back to "trident"
Similar issue with cirrus driver: bug #437081. This could be an X-wide issue, not limited to a few drivers, I suspect, see also: http://www.redhat.com/archives/fedora-test-list/2008-March/msg00421.html
Assigning to ajax, to whom it belongs (looks like either Xserver issue or trident issue), but could I ask you as well to try to move /etc/X11/xorg.conf somewhere behind the corner and then to restart X (or whole computer) without the one? What happens? Could we get /var/log/Xorg.0.log from this experiment as well, please?
(In reply to comment #5) > Assigning to ajax, to whom it belongs (looks like either Xserver issue or > trident issue), but could I ask you as well to try to move /etc/X11/xorg.conf > somewhere behind the corner and then to restart X (or whole computer) without > the one? What happens? Could we get /var/log/Xorg.0.log from this experiment as > well, please? The /var/log/Xorg.0.1 in the attachment *is* the result of that experiment.
Attachment #297352 [details] notes that there was no /etc/X11/xorg.conf at the time I took the /var/log/Xorg.0.log: "(EE) Unable to locate/open config file" this was taken right after a reboot.
Should be fixed in xserver 1.4.99.901-4
Just confirming that xorg-x11-server-Xorg-1.4.99.901-6.20080310.fc9.i386 pulled manually from koji here: http://koji.fedoraproject.org/koji/buildinfo?buildID=42769 does appear to get X to start (with trident). Thanks! Although there are some issues with choosing too small a resolution mode when no xorg.conf is present, but that's another issue (bug #433423).