mapping single-key input devices to buttons

[Johannes Berg]

Hi,

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

That's the question. I'm no longer sure this approach is good, because
we end up with tons of input devices. I'd probably prefer in the kernel
to have just a single one for the PMU.

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

Yes, that was my thinking. However, I think I'll give up the button
thing. What use is differentiating between a 'power button' and a
'keyboard with a power button'? And how to do that?

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

Oh could be, I thought I looked at an example but...

>  You also want to 

>  1. add the capability 'button' to the info.capabilities properties.

I did and it turned up twice because this event device already had it. I
should probably check if it's present and if not add it.

>  2. set the boolean button.has_state to FALSE

Good point.

> and then you should be all set. Comments?

I think you should only apply the part of the patch that fixes the
endianness stuff and drop the check_btn at all. I'm no longer convinced
that it is the right approach, see above.

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

Yeah, but the power button doesn't have state. Well, if you press it for
longer than a couple of seconds the machine turns off, at least for
me :->

So, to recap, we shouldn't be using buttons from the input device stuff
because we can't query the state.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 793 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/hal/attachments/20060501/99ba17e4/attachment.pgp