"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. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
