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 _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
