On Wed, Jan 28, 2009 at 10:17 AM, Agathoklis D. Hatzimanikas <[email protected]> wrote: > On Wed, Jan 28, at 08:40 Dan Nicholson wrote: >> >> 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? >> > > It was just the input devices. I am able to ssh from another machine and > that's how I killed X and went back to a virtual console. > For your information here is a relevant part from a working X: > > X.Org X Server 1.5.3 > Release Date: 5 November 2008 > X Protocol Version 11, Revision 0 > Build Operating System: Linux 2.6.27.6 i686 > Current Operating System: Linux AH 2.6.27.6 #3 SMP Wed Nov 19 08:30:17 EET > 2008 i686 > Build Date: 27 January 2009 11:48:14PM > ... > > (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 28 19:38:36 2009 > (==) Using config file: "/usr/lib/X11/xorg.conf" > (==) ServerLayout "Layout0" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "NVIDIA Corporation NV40 [GeForce 6200 TurboCache]" > (**) |-->Input Device "Keyboard0" > (**) |-->Input Device "Mouse0" > (**) Option "AllowEmptyInput" "false" > (==) Automatically adding devices > (==) Automatically enabling devices > > And here what is logged after commented out the option and starting xorg > with "-logverbose 10" > > (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be > disabled. > (WW) Disabling Keyboard0 > (WW) Disabling Mouse0
Could you attach the log and your xorg.conf from a failed run? >> > 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. >> > > I will be happy to check, maybe at the weekend a recent server snapshot. I just took a look, and I think all that's changed since 1.5.3 is a different warning. Probably not worth the upgrade just to narrow this down. >> 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? > > Yes 1.5.3. > And another thing that I've remembered. > As I am a multi language environment I just don't know how I suppose to > change keyboard layout (see Xkboptions and XkbLayout), when in fact Xorg > (if I got it right) ignores the InputDevices sections. It all boils down to the same issue: whether input devices from xorg.conf are being used or not. If HAL is not being used, the xorg.conf devices should always be enabled, but I don't think that's the case as you found out. The main reason for doing this at all is that you'd often get duplicate devices when the HAL hotplugging was enabled and you have devices listed in xorg.conf. Then you have stuff like duplicate key presses happening. If we can figure out exactly where the logic is falling apart, I can try to submit a patch upstream. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
