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

[Nix]

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.