On Wed, Jan 28, 2009 at 6:15 AM, Agathoklis D. Hatzimanikas <[email protected]> wrote: > Hi, > > On a recent Lfs build (a copy of a middle December) I've installed > (with no problems) the latest Xorg release 7.4 by following book > instructions. > > But when I've tried to log in X, I've faced some problems: > > The first error was about that "RgbPath" wasn't not a valid keyword. > By commenting out the relevant line I was able to continue. > > The second one was about the "record" module, I did the same as before > and I was able to continue. > > The third one was the famous error "couldn't find default font fixed", > and although I've done all the usual steps, I wasn't able to fix this, > so I just cheated and by blatantly copied the fonts from an old working > system I was able to continue. I don't know exactly the reason for this > failure, both the "font-alias" and "bdftopcf" packages was installed > properly with no error.
This one is tough because there are a lot of ways it can fail. If copying old fonts into the same path that was giving you problems works, then that probably means that something in the font toolchain was broken during the installation. That usually means bdftopcf, mkfontdir or mkfontscale. I think you want to have font-alias and encodings installed before you start installing any fonts since mkfontdir/mkfontscale operate on them. One thing to keep in mind is that you have to run mkfontdir/mkfontscale post-install if you're using a DESTDIR. > The fourth is basically the reason for this email, so the solution can be > archived for reference to people with the same problem. > > > Now, when I've tried to log in X, my computer just locked. I couldn't > use the mouse, I couldn't use the keyboard to switch to virtual consoles, > so basically it left nothing else other than a hard reset (after years > without one, that was an unpleasant experience). The graphics locked, too, or just the input devices stopped responding? Usually if the computer locked, it's the graphics device getting wedged. Can you ssh in from another machine while this is happening? What chipset are you using? Can you post an Xorg.log from when this happened? > I've looked to the Xorg log but I couldn't find an obvious reason for > this, so and because I wanted to be sure first (before to start > reporting) I fall back to the know good versions of Xorg to see if they > are working on the same exact system and apparently they did. > I've then tried to build Xorg without Mesa, but I've had the same hard lock. > > So, I've started to look in the Xorg lists and I've found two similar > problems within the last days. The solution was pretty easy, I just wanted > to put to the "ServerFlags" section the following line: > > Option "AllowEmptyInput" "false" > > >From man xorg.conf: > ====================================================================== > Option "AllowEmptyInput" "boolean" > If enabled, don't add the standard keyboard and mouse drivers, > if there are no input devices in the config file. Enabled by > default if AutoAddDevices and AutoEnableDevices is enabled, oth- > erwise disabled. If AllowEmptyInput is on, devices using the > kbd or mouse driver are ignored > ====================================================================== > > As I understand it, this is actually a feature. > I think (not sure) Xorg uses Hal for (keyboard and mouse) auto detection. > But as I didn't have Hal installed that (feature) transformed into a bug. > > This also happened even if I explicitly passed to the "xorg server" configure > options the "--disable-config-hal" switch, plus also configure doesn't > find hal in $PATH, see: > > Checking for HAL... no I haven't looked at the logic in a while, but I think that if the HAL config is not built, then the AllowEmptyInput setting shouldn't matter. I could be wrong on that, though, and there have certainly been recent commits to get this to work correctly more often. Another thing to consider is to just use evdev even for xorg.conf devices. There are very few devices left on Linux that don't work correctly with evdev. > If I am right and I haven't done any mistake other than I don't want to > use Hal, is it possible over in Xorg, to do something to prevent this from > happening? Maybe a conditional check that could raise even a fatal error? > For me that would be acceptable; I'd rather have one than to have locked > from using the computer at all. Although a non-HAL xorg is becoming more rare, that configuration should be supported. There may be bugs in the logic on how to decide whether devices from xorg.conf are honored. This is xorg-server-1.5.3, right? > Additionally a little more generosity in verbosity would me more than > welcomed, so users can spot more easily these kind of problems, a "big > fat warning" or something like that. You can run Xorg with -logverbose N where N sets the verbosity level from 1-10. The default is 3. I don't know if this will be really informative for input devices, though. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
