Re: ACPI: thinkpad-acpi: make the input event mode the default

Matthew Garrett
2007-07-15T22:49:14Z

On Sun, Jul 15, 2007 at 07:08:01PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > Right now, the hotkey functionality of the driver is not terribly useful
> > without (bleeding-edge) userspace. This is inconsistent with the
> > majority of input drivers which do something broadly sane in that
> > situation.
>
> It works better with non-bleeding-edge userspace the way I did it, as far as
> I know. So I'll need some explanations about what I should be doing
> differently.
>
> Here's my view on things:
>
> Non-bleeding-edge userspace screws up volume control if I send events. And
> so does bleeding-edge userspace for that matter, AFAIK.

No, it doesn't. It interacts in a way that you may not consider to be
ideal - the vast majority of our users appear to prefer it to the
previous behaviour, so it's better than nothing.

> Non-bleeding-edge userspace screws up brightness control if I send events.

No. Nothing will screw up if you send brightness events.

> Bleeding-edge userspace needs to be told it exists, anyway, to make proper
> use of it, and can be told to enable it on the driver while at it.

We've been listening for KEY_BRIGHTNESS* on Thinkpads for over a year.
It's already implemented and works fine.

> Non-bleeding-edge userspace that is not broken can remap keys already.
> FN+F1 generating KEY_FN_F1 makes a lot more sense to someone which has a
> blank FN+F1 key, than it generating "KEY_FOOBAR".

That's fine. Send KEY_FN_F1 if there's no label.

> So exactly what should I be changing to make it more useful? WHAT hot keys
> do you want mapped by default, and to which key codes? And forget the ones
> that need passive handling, these are not mapped for a very different
> reason.

On a machine with a glyph, the driver should generate a keycode
appropriate for that glyph.

--
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org