Re: ACPI: thinkpad-acpi: add input device support to hotkey subdriver

Henrique de Moraes Holschuh
2007-07-15T20:03:38Z

On Sun, 15 Jul 2007, Matthew Garrett wrote:
> > No. This is handled in firmware in IBM thinkpads, and userspace only screws
> > it up. I am tired of watching people get this routed to the AC97 mixer by
> > default. That is a fringe configuration that only makes sense when using a
> > dock, and with the audio tied to the dock's audio port, in *all* thinkpads
> > but (_maybe_) the *61.
>
> It should either generate a KEY_VOLUMEUP or it should generate something
> explicitly defined as KEY_VOLUMEUP_PASSIVE. The proposed configuration

Well, it will someday (2.6.24)? be an alsa mixer. The mixer generates
events when changed, and you could get that info from there.

I'd be happy to provide a VOLUMEUP_PASSIVE, but it doesn't exist. I'd be
even happier to have an EV_KEYNOTIFY to use instead of EV_KEY that has the
explicit notion that "something else will handle the active effects of this
key, this is a FYI event only".

> (send something that does nothing, but include an arbitrary scancode)

It doesn't send anything on the input device if it is set to KEY_RESERVED.
It does send an ACPI ibm/hotkey event, but that is a compatibility
interface.

> adds complexity and does nothing other than avoid a (harmless) odd
> result.

I do not consider screwing up the mixer handling a harmless result.

> > Let hal enable it if it needs it for OSD, and I sure hope HAL is wise enough
> > to do passive handling only for the events that come from the thinkpad event
> > device, because if one has an external multimedia keyboard, its volume keys
> > should go to the AC97/HDA mixer.
>
> That's fine. One will be coming from the i8042 (or USB) and the other
> will be coming from thinkpad_acpi. We already have the information
> needed to do something sensible there - we don't need to have different
> keycodes to determine which is which.

Good. Not that I'd have anything against giving you an explicitly
*passive* event, but there is no such a beast. Give one to me, and I shall
use it.

Until then, since the default meaning of *all* KEY_ events are active in
nature, I am against the idea of generating events that are to be handled in
a passive way, by default.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh