mapping single-key input devices to buttons
David Zeuthen
david at fubar.dk
Mon May 1 08:38:22 PDT 2006
Hi,
Sorry for the lag; I was out all weekend.
On Sat, 2006-04-29 at 00:25 +0200, Johannes Berg wrote:
> After some discussion on IRC I came up with the following patch.
>
> I *don't* understand why any input devices get a 'button' capability,
> and this isn't addressed by my patch. If that capability is removed (I
> wouldn't have expected it to be present after discussing this with
> davidz), then the check_btn routine needs to add it. It should also
> probably handle more types of buttons...
>
> In any case, this patch fixes an issue with test_bit -- a kernel
> compatible implementation should be used or junk ensues.
Yes, so, just to recap, the case is that the kernel, for each physical
button exports a single input device with a single key, yes? And the
thinking is that the patch discovers this on the input device and makes
it into a button, yes? [1]. I think that makes sense in some kind of
interim until someone fixed this properly in the upstream kernels [2].
So I think the patch almost looks right;
+ libhal_device_property_strlist_append (ctx, udi,
"button.type", "power", &error);
+ break;
+ case KEY_EJECTCD:
+ libhal_device_property_strlist_append (ctx, udi,
"button.type", "eject-cd", &error);
so, I think button.type is of type 'string'. You also want to
1. add the capability 'button' to the info.capabilities properties.
2. set the boolean button.has_state to FALSE
and then you should be all set. Comments?
David
[1] : Because that's what we do with all normal keyboards (capability
'input.keyboard') via 10-keyboard-policy.fdi with the caveat that we
don't know what buttons it might export.
[2] : What's the right fix? Personally I think, for Linux, that there
ought to be some kind of sysfs class 'button' or something. It's just
not a keyboard since some buttons can indeed have states (like the lid
button). I'm alright though with using an input device as the
notification mechanism... but I don't really know..
More information about the hal
mailing list