On 6 Oct 2009, Peter Hutterer said: > On Tue, Oct 06, 2009 at 03:22:02PM +0100, Nix wrote: >> 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. > > This is exactly the thing I was referring to in my previous email. Your > configuration is wrong, it dates back to some period where this actually > fixed some bug. The only reason why it works in your case is because HAL - > even if running - is not set up correctly.
In that case *HAL upstream* is not set up correctly when installed. Since the only reason I installed HAL was to placate software that insisted on having it installed before building it, my system has a constant set of hardware which doesn't change every five minutes, and HAL's configuration is entirely undocumented, this is hardly surprising. If HAL upstream is broken, then the fault lies with HAL upstream. > When you have AEI off, the server will require a CorePointer and > CoreKeyboard device in the config (and create default devices if not found). > The same devices will then be added thanks to HAL, resulting in duplicate > button presses and triple key presses*. ... which are not observed here. That I've configured the X server with --disable-config-hal is possibly relevant. I suspect that with AllowEmptyInput on, the server is attempting to get devices from HAL alone even when it hasn't been compiled with HAL support, and ends up getting devices from nowhere. Possible? > If you don't want to use HAL that's fine with me, the correct option to > disable it is 'AutoAddDevices "off"' though. Just turning AEI off causes > issues when HAL works correctly. None seen, because X here doesn't talk to HAL at all (I like X to work even in the fairly frequent event that HAL decides that coredumping is better than booting this week). > * incidentally, the same thing will happen once we have udev support instead > of HAL. That might be worth looking at then. Configuring the keyboard via udev appears quite easy, if the stanzas already posted on the mailing list are any guide. (It's probably most sensible for X to ship some samples, even if it doesn't install them by default.) It does mean that people not running udev are going to be screwed, but that's pretty much only embedded systems these days, and they're *used* to configuring absolutely everything by hand. See, that's not what I'm objecting to. It's the way that the upgrade to x11-xserver 1.5 left me with a non-working keyboard because of this mess, and then so did the upgrade to 1.6, because the meaning of existing configuration keys had *changed*! X used to be really, really good at backward compatibility... (though of course it also used to be so slow-moving it was indistinguishable from the dead. Still it would be nice if some of these whizzy new features got documented somewhere X-related rather than just landing in random blog posts and mailing list threads scattered around the web. I can understand your not doing it, you've been trying to document Xkb and that would drive anyone to despair ;P but it's annoying that nobody is doing it that I can see.) Just a random from-source-user's perspective... _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
