On 6 Oct 2009, Daniel Stone told this: > Hi, > > On Tue, Oct 06, 2009 at 03:22:02PM +0100, Nix wrote: >> On 13 Sep 2009, Peter Hutterer spake thusly: >> > I still see configurations with AllowEmptyInput off because there was a >> > brief period when that fixed a certain broken setup. Now people use it >> > because they read it somewhere and thought it's a good idea. >> >> Actually I use it because with it off my keyboard is ignored unless HAL >> is running, even as of X.org 1.6.x, and HAL is an unreliable POS which >> failed to start for *years* for me, so I am reluctant to rely on it for >> anything. > > Have you got the relevant FDI files installed? Does lshal | grep x11, > show anything?
Pass. Which FDI files are relevant? I have what came with hal-info 20090414. (as an aside rant, FDI is *also* entirely undocumented except for a laughably outdated spec file which is only available these days in the HAL source tree, and a series of despairing blog posts from people who've tried to reverse-engineer the bloody thing. Still, FDI is dead along with HAL now. I'll see if I can forget all about both of them. udev is *very* much more reliable, nicer to use, and easier to debug problems with, thank goodness X is moving over to it.) >> It's not all cargo-culting, unless you consider 'keyboard doesn't work, >> turn this option on and now it does' to be cargo-culting. >> >> (Note that this may have changed since 1.6.2, when I tried it last, but >> I doubt it's changed much since then.) > > It should work just fine with both 1.6.2 and master. I'll try it again soon. >> (As an side, this is all with kbd+mouse. I have never managed to coerce >> evdev into working at all, so I'm using kbd because, well, it doesn't >> seem to have any disadvantages. Maybe it can't deal with some key or [...] > There are many well-documented reasons to use evdev, which I won't > rehash in depth, They don't seem to be hashed anywhere. Maybe in a years-old mailing list post somewhere which my google-fu is not competent to find... > but among them are the ability to address keyboards > independently, including different layouts for each, extended keycode > support, None of which are remotely relevant if you have a normal system with one keyboard. Hell, I have two, one is extremely unusual (a Maltron), I often have both connected and in use at the same time, and kbd *still* works, probably because both are roughly QWERTY. > not having to use the TTY layer (kbd is unbelievably fragile > and complex), etc, etc. Avoiding the horrible TTY layer is probably a major advantage :) but not for the user... > If your setup doesn't work at all, having followed the instructions for > doing so that Peter posted quite a while back, 'Posted quite a while back' isn't terribly useful as far as documentation goes. I set the driver to evdev and said Option "XkbRules" "evdev" and got a dead keyboard for my troubles. But I haven't tried for a month or two so this may all be irrelevant. I'll upgrade to 1.7 (well, the katamari including 1.7) and try again. > please file bugs and > we'll fix the evdev driver if it is in any way deficient. I very much suspect that what is deficient is the documentation. I'm willing to believe that this stuff *does* work if you know how to set it up, but that the only way to tell how to set it up is to look at an already-working system --- and most systems I use are Debian, and use kbd. _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel