Red Hat Bugzilla – Bug 397461
Xorg -configure is broken
Last modified: 2018-04-11 10:50:51 EDT
Description of problem:
Since F8 it is not possible anymore to use "X -configure" to let the X server
generate a default config for the current hardware.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. X -configure
"Missing output drivers. Configuration failed."
"Xorg detected your mouse at device /dev/input/mice.
Please check your config if the mouse is still not
operational, as by default Xorg tries to autodetect
Your xorg.conf file is /root/xorg.conf.new
To test the server, run 'X -config /root/xorg.conf.new'
The problem is caused by one of the applied patches:
This patch changes the file xorg-server-18.104.22.168/hw/xfree86/loader/loadmod.c and
reverts the meaning of the following statement:
- if (!(stat(buf, &stat_buf) == 0 &&
+ if (dp->d_type == DT_REG)
Before the patch it will not proceed the loop if the file isn't a regular one.
After the patch it will not proceed the loop if the file is a regular one (and
so it doesn't find any output drivers and so it doesn't work. ;-) ).
IMHO the part of this patch file which changes loadmod.c are not really
necessary or change any behavior. I suggest that they are removed from the patch
I'll attach a corrected diff.
Created attachment 267811 [details]
new version of the patch
Any news regarding this issue? Is there anything I can do to help to fix the
Does system-config-display works for you? Are you able to start X when remove
/etc/X11/xorg.conf completely? I am afraid we don't care that much about X
Actually system-config-display doesn't work with my dual-head configuration (but
this is a different problem)
when using system-config-display without a xorg.conf it basically works (unless
dual-head is configured, then the config cannot be saved)
IMHO these system-config-display problem should be handled separately. ;-)
Starting X without having an /etc/X11/xorg.conf works.
I understand that "X -configure" is probably not a common use case anymore. But
a co-worker stumbled over this and I've given it a shot to check for the
problem. It turned out that it was caused by one of the patches from Fedora, so
I've thought I should report the problem. ;-)
Please can you review my investigation I've put into the description and the
attached patch? The problem only occurs because there is a (broken) patch
applied when building the package. Because the broken chunks of the patch does
not even have an effect to fix the (original) bug which the patch was created
for (some ps2 problems), I've stripped it from the patch and created a new one.
Right you are, the module loader chunk there was included accidentally.
Building this as 22.214.171.124-42, update will go out momentarily.
xorg-x11-server-126.96.36.199-42.fc8 has been submitted as an update for Fedora 8
xorg-x11-server-188.8.131.52-42.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update xorg-x11-server'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1542
Not a F9 bug, removing from F9 blocker.
xorg-x11-server-184.108.40.206-42.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
With the latest update the problem is fixed. Thank you very much!
The bug status can now be changed to "RESOLVED CURRENTRELEASE", version: