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