Duncan wrote:
"Mark Haney" <[email protected]> posted
[email protected], excerpted below, on Sat, 07 Mar 2009
00:51:02 -0500:
Well I upgraded my xorg-server from 1.3.0 to 1.5.3 (masked) in order to
overcome some of the KDE4.2 blocks I was encountering (for some
particular kde4.2 package, which escapes me for the moment.
So I ungraded, updated my ati driver (I use the radeon driver not one
from ATI) and now my X server won't start. It says 'X server died on
start up' and 'Can't start display on 0:0' or something similar, I'm
writing this on the same box from a different OS. What next? How do I
fix this?
I don't believe 1.5.3 is masked, only ~arch. Unless that's what you
meant by masked... Now xorg-server-1.6.0, if it were in the tree (it's
in the xorg overlay not the tree at this point), would be masked, as
there are still some issues with it, including that some of its
dependencies don't have sufficient released versions yet, it requires git-
live builds for some of them.
There were a LOT of changes in the way things worked between 1.3.x and
1.5.x. I STRONGLY suspect that your xorg.conf file simply isn't
configured correctly for the newer version, thus X dies when you try to
start it.
What input drivers are you using? It /may/ be as simple as adding the
following line to the ServerFlags section (you may use "false" or "off"
instead of "0" if you prefer):
Option "AllowEmptyInput" "0"
The reason is that xorg now ignores the xorg.conf configured input
drivers and tries to hotplug them (using hal) if you don't tell it not
to. Except, the hotplug will try to use the newer evdev driver which you
may not have the INPUT_DEVICES setup for, instead of the older keyboard
and mouse drivers which you likely have installed and configured in
xorg.conf, if you are updating from a suitably old xorg configuration.
Now, if your keyboard and mouse settings are vanilla enough, you can
switch to the evdev driver and just let xorg-server hotplug it, no
problem. However, if you have something other than a generic 102-key (or
whatever) keyboard or a standard mouse, the evdev driver will need
additional configuration or you'll lose that additional functionality and
just have the generic functionality. The problem is that the hal
hotplugging configuration isn't all that clearly documented yet,
especially for all the permutations of hardware special features out
there, so it may be difficult actually finding instructions for doing
that configuration if you need it.
The other option, easier if you already had a working configuration using
the existing keyboard and mouse (or other inputdev) drivers, and just
want it to work like it did before, is to put the line above in the
serverflags section of xorg.conf, so it actually honors the xorg.conf
input device configuration.
The other thing that may have changed, depending on what version of
xf86-video-ati you are running, is that the newer configuration (from
version 6.8 at least, 6.6 was still the old way) is all RandR based. For
a normal single-monitor system, it should still work with little problem,
but for a dual-monitor or more system, again, there's configuration
changes you'll need to work thru. This is the part that was hardest for
me, since I effectively punted on figuring out the inputdev stuff by
simply adding the line above in the appropriate place.
But that's rather more complex. If the above added line doesn't fix it,
post your Xorg.0.log, xorg.conf, and the output of an
emerge --pretend --verbose xorg-server xf86-video-ati xf86-input-<driver>
(whichever ones you use).
Meanwhile, all these changes are to make it ideally "just work", for most
people. Most people will have all the various drivers already installed
or available, and xorg-server and hal are normally able to detect which
drivers are needed and configure them appropriately -- provided nothing
goes wrong and the hardware isn't too exotic. If you have the evdev
driver available already, are content with a generic keyboard and mouse
setup, and either don't have multiple monitors or aren't too particular
about what orientation and resolution they end up in, it's quite possible
you can run without an xorg.conf entirely, now.
Well, here's an update on this problem. I didn't get a chance to work
on it at all yesterday since I wanted to spend time with the kids.
So, here's the deal. Duncan, I added that option to the 'ServerFlags'
section and it made no difference at all. In dmesg I get ''X server
died during startup' 'X server for display :0 cannot be started, session
disabled'
I had been running 1.3.x without an xorg.conf file for a couple months
now without trouble. The above message happens both with and without an
xorg.conf file. So, what I'm going todo right now is recompile all the
X11 drivers and see if that helps.
--
Mark Haney
[email protected]
Fedora release 9 (Sulphur)
Kernel: 2.6.27.9-73.fc9.i686 GNU/Linux
06:48:33 up 11 days, 11:54, 2 users, load average: 0.28, 0.18, 0.11