[Debian-eeepc-devel] 1201PN Fn key problems

[Ben Armstrong]

On 03/05/11 12:21 AM, Perry Thompson wrote:
> That fixed my volume keys, however in my quest to find the problem, I
> did something to mess up my mute Fn key, my blackout screen Fn key, and
> my brightness Fn keys. Mute works kind of backward, it I press it while
> a song is playing, it mutes it but shows that it's not muted, when I
> press it again it will unmute it for a split-second then remute it. If I
> press the volume up or down Fn keys it will play sound again, but it
> shows the X on it that it is muted.

This behaviour of mute is consistent with double handling of the Mute
key, once by eeepc-acpi-scripts and once by GNOME. We've been over
/etc/default/eeepc-acpi-scripts before on irc, but perhaps you could
post it to this thread for reference. All of the sound keys should not
be hooked up to their handlers when you use GNOME, letting GNOME itself
handle those keys (i.e. set them all to NONE).

> The blackout screen Fn key just
> plain doesn't work,

This could again be double handling of keys.

> and the brightness keys no longer show the
> notification (the bar of how bright it is).
>
> I have noticed that my notification-daemon is not running when I run my
> system as well. Here is some information that may prove useful to anyone
> who can help me.

As I indicated on irc, the lack of a running notification-daemon
explains why the brightness bar is no longer shown. I'm puzzled as to
how this can be, as you say you run GNOME, and I thought that on a GNOME
system notification-daemon (if installed) will always be started. So I
think somehow your GNOME session isn't started properly.

> The only things I can think of that I may have done to cause this are
> update my BIOS and purge acpi-support and eeepc-acpi-scripts back and
> forth trying to find where my problem lay. I since reinstalled an old
> BIOS (I think it was the one I had had before), but it changed nothing.
> 
> I also tried purging acpi-fakekey and rfkill which are required by
> acpi-support and eeepc-acpi-scripts, respectively.

rfkill is a dependency of eeepc-acpi-scripts. It cannot be removed
without removing eeepc-acpi-scripts (nor is its presence relevant to
this problem in any case).  acpi-fakekey is not required for
eeepc-acpi-scripts 1.1.10.

> When I remove the acpi_osi=Linux everything works perfectly normal
> again, aside from the non-working volume Fn keys, which is to be
> expected, so I think it has something to do with the eeepc_laptop module
> or acpi.

ACPI-related for sure. I'm almost certain eeepc-acpi-scripts is handling
those volume keys when it shouldn't be, in spite of your report that you
have configured it to not bind handlers to those keys. So our
investigation should focus on detecting whether this is the case or not.
Press these keys and observe in /var/log/syslog whether they are handled
or not. For example, when I press the volume-up key, I get the following
output (using asus_wmi on the 2.6.38 kernel and git version of
eeepc-acpi-scripts, so output may differ from yours):

May  3 05:58:11 shade acpid: received input layer event "button/volumeup
VOLUP 00000080 00000000"
May  3 05:58:11 shade acpid: rule from 1366[0:0] matched
May  3 05:58:11 shade acpid: notifying client 1366[0:0]
May  3 05:58:11 shade acpid: rule from
/etc/acpi/events/asus-eee-hotkey-button matched
May  3 05:58:11 shade acpid: executing action
"/usr/share/acpi-support/eeepc-acpi-scripts/button.sh button/volumeup
VOLUP 00000080 00000000"
May  3 05:58:11 shade acpid: action exited with status 0
May  3 05:58:11 shade acpid: 2 total rules matched
May  3 05:58:11 shade acpid: completed input layer event
"button/volumeup VOLUP 00000080 00000000"
May  3 05:58:11 shade acpid: received netlink event " PNP0C14:00
000000d2 00000000"
May  3 05:58:11 shade acpid: rule from 1366[0:0] matched
May  3 05:58:11 shade acpid: notifying client 1366[0:0]
May  3 05:58:11 shade acpid: 1 total rule matched
May  3 05:58:11 shade acpid: completed netlink event " PNP0C14:00
000000d2 00000000"

I am using LXDE with no handler for the volume keys in the desktop
environment / window manager, so this behaviour is correct (i.e. in this
case I do have handlers bound to these keys in
/etc/default/eeepc-acpi-scripts and therefore do expect to see the rules
triggered in the log). In your case, you don't want to see these rules
triggered or else, as I said, they'll be handled twice, leading to the
strange mute toggling behaviour you observed.

Ben