[PATCH] Add configuration option for use of SIGIO handlers for input events

[Nix]

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...