Brightness hotkeys misdetected on Eee Pc

> ACPI events, bare for a few exceptions, are now handled either
> directly by the kernel input layer, or other subsystems, like UPower.

But there *are* exceptions, which is why the package is still around.

Could you tell us which ACPI events are the ones getting duplicate handling on your system, so we can remove the handlers from the package?

> But there *are* exceptions, which is why the package is still around.

Right, but we haven't these exceptions been fixed yet? And why does acpi-support ship so much stuff that is clearly deprecated?

The problematic events are "asus-brightness-down" and "asus-brightness-up".

On Thu, Mar 15, 2012 at 12:00:49AM -0000, greg wrote:
> > But there *are* exceptions, which is why the package is still around.

> Right, but we haven't these exceptions been fixed yet?

The exceptions are the events for which neither the kernel nor the
freedesktop framework provides handling. So there's no way to "fix" these
until the upstream stack provides standard handling for touchpad and
wireless toggling keys.

> And why does acpi-support ship so much stuff that is clearly deprecated?

The handlers that are probably deprecated are mostly those for ASUS and
Toshiba hardware, which no one who works on this package has direct access
to. If you can confirm which of the other /etc/acpi/events/asus-* handlers
are already handled through the kernel input layer, I'm happy to remove
those as well.

> The problematic events are "asus-brightness-down" and "asus-brightness-
> up".

Could you please run acpi_listen and show the actual ACPI events generated
for each of these keys? This may be important later in case a different
ASUS model isn't being handled correctly in the kernel yet.

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

> The handlers that are probably deprecated are mostly those for ASUS and
> Toshiba hardware, which no one who works on this package has direct access
> to.

At least on Asus notebooks everything should be handled through the kernel, with the asus-laptop module.

> Could you please run acpi_listen and show the actual ACPI events generated
> for each of these keys? This may be important later in case a different
> ASUS model isn't being handled correctly in the kernel yet.

The eeepc-laptop driver generates ATKD events in the range 0x20 to 0x2f, depending on the current brightness, where 0x20 is the lowest setting and 0x2f is the highest. For instance:

increment:
hotkey ATKD 0000002c 00000003
hotkey ATKD 0000002e 00000006

decrement:
hotkey ATKD 0000002c 00000004
hotkey ATKD 0000002a 00000004

This conflicts with the asus-brightness-down acpid event, which matches all of these events, no matter if the brightness is actually incremented or decremented.

On Thu, Mar 15, 2012 at 11:34:55PM -0000, greg wrote:
> > The handlers that are probably deprecated are mostly those for ASUS and
> > Toshiba hardware, which no one who works on this package has direct access
> > to.

> At least on Asus notebooks everything should be handled through the
> kernel, with the asus-laptop module.

Well, I'm pretty sure that there's nothing that's going to handle what
/etc/acpi/events/asus-touchpad does, for instance. Could you help to verify
for each of the events listed for /etc/acpi/events/asus-* that, first, you
have a hotkey that outputs the same ACPI event on your system, and second,
that it performs the correct system function even when acpid isn't running?

> > Could you please run acpi_listen and show the actual ACPI events generated
> > for each of these keys? This may be important later in case a different
> > ASUS model isn't being handled correctly in the kernel yet.

> The eeepc-laptop driver generates ATKD events in the range 0x20 to 0x2f,
> depending on the current brightness, where 0x20 is the lowest setting
> and 0x2f is the highest. For instance:

> increment:
> hotkey ATKD 0000002c 00000003
> hotkey ATKD 0000002e 00000006

> decrement:
> hotkey ATKD 0000002c 00000004
> hotkey ATKD 0000002a 00000004

> This conflicts with the asus-brightness-down acpid event, which matches
> all of these events, no matter if the brightness is actually incremented
> or decremented.

Thanks, I've dropped these from the package branch, so this should be fixed
in the next upload.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

> Well, I'm pretty sure that there's nothing that's going to handle what
> /etc/acpi/events/asus-touchpad does, for instance. Could you help to verify
> for each of the events listed for /etc/acpi/events/asus-* that, first, you
> have a hotkey that outputs the same ACPI event on your system, and second,
> that it performs the correct system function even when acpid isn't running?

You're probably right, for the various very special keys like touchpad toggle, video mode toggle, etc. there is no handling available outside of acpid. However, keys for WiFi/bluetooth toggling, volume, brightness and media player control should work without any acpid help. I cannot verify that for every Asus Laptop, of course.

Also, sorry for being so inconsiderate in the OP.

This bug was fixed in the package acpi-support - 0.141

---------------
acpi-support (0.141) quantal; urgency=low

  [ Steve Langasek ]
  * drop asus-brightness-{up,down} handlers and asus-brn-{down,up} scripts.
    LP: #955176.

  [ Timo Aaltonen ]
  * asus-touchpad.sh: Don't handle Synaptics devices. (LP: #804109)
 -- Timo Aaltonen <email address hidden> Tue, 09 Oct 2012 13:32:35 +0300