Red Hat Bugzilla – Bug 757928
HP HDX 9494NR: Touchpad toggle on/off not working
Last modified: 2013-02-25 21:44:42 EST
My HP HDX 9494NR laptop has a toggle button with LED above the touchpad that is supposed to enable or disable the touchpad. When i press the button the LED changes state (probably controled via firmware) but the touchpad is still enabled. Clicking the Touchpad does generate these messages when i view dmesg: atkbd serio0: Unknown key pressed (translated set 2, code 0xd8 on isa0060/serio0). atkbd serio0: Use 'setkeycodes e058 <keycode>' to make it known. atkbd serio0: Unknown key pressed (translated set 2, code 0xd9 on isa0060/serio0). atkbd serio0: Use 'setkeycodes e059 <keycode>' to make it known. The first two messages relate to disabling the touchpad, and the second two relate to enabling the touchpad. Sorry if this shouldn't be put under udev. i saw a similar bug for a different latoptop model and it was under udev, so i was guessing that that was the correct component. Please let me know what additional information you need and i will do my best to get it for you.
I have been trying to figure out how to address this (i saw these two similar bugs that i followed but it still doesn't work https://bugs.launchpad.net/ubuntu/+source/udev/+bug/554944 and https://bugzilla.redhat.com/show_bug.cgi?id=366211) $ cat /sys/class/dmi/id/sys_vendor Hewlett-Packard $ cat /sys/class/dmi/id/product_name HDX9494NR I tried setting up a keymap file in /lib/udev/keymaps: $ cat /lib/udev/keymaps/hewlett-packard-hdx9494nr 0xB2 www # FnF3 0xD8 f22 # touchpad off 0xD9 f23 # touchpad on and added a rule to /lib/udev/rules.d/95-keymap.rules: ENV{DMI_VENDOR}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="HDX9494NR*", RUN+="keymap $name hewlett-packard-hdx9494nr" after rebooting (i can't figure out a better way to get udev to rerun the rules, restarting udev doesn't seem to do the trick), the only new keymapping that works is the www one which opens the browser, but the touchpad still remains on. they messages are gone from dmesg however. is there something i am missing? my guess is that f22 and f23 don't mean anything to my system, but i don't know what else to use for those values.
I made a little more progress: after adding a keyboard-force-release rule entry, i now see the OSD for when i enable or disable the touchpad. the touchpad still continues to function however. I added a rule to /lib/udev/rules.d/95-keyboard-force-release.rules: ENV{DMI_VENDOR}=="Hewlett-Packard*", ATTR{[dmi/id]product_name}=="*HDX9494NR*", RUN+="keyboard-force-release.sh $devpath hp-other" I now see the OSD for when I disable or enable the touchpad, but the touchpad remains usable in the disabled state. How can i look into this further?
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I just installed Fedora 18 and this is still not working as expected. I do not know where to start on this, and would appreciate at least a response from someone since this bug is now over a year old.
(In reply to comment #1) > after rebooting (i can't figure out a better way to get udev to rerun the > rules, restarting udev doesn't seem to do the trick) No, that won't, but running this as root should do: udevadm trigger --verbose --subsystem-match=input > the only new keymapping that works is the www one which opens the browser, but the > touchpad still remains on. they messages are gone from dmesg however. OK, that shows that the key codes were assigned correctly. You can also verify this in "xev", when you press the touchpad enable buttons you should see some key events showing XF86TouchpadOn/Off. If you only see the "key press", but not the "key released" event, then you need the keyboard-force-release rule entry which you already set up; if you still see "key release" without that (you need to reboot after removing the rule), then the force-release rule is not necessary. > is there something i am missing? my guess is that f22 and f23 don't mean > anything to my system, but i don't know what else to use for those values. Indeed there are no defined Linux key codes for "touchpad off/on/toggle", so there has been an agreement to interpret F21/22/23 as toggle/on/off: http://lists.x.org/archives/xorg/2010-November/051533.html https://bugs.freedesktop.org/show_bug.cgi?id=31333 So it would be nice if you could check xev whether the problem is on the key mapping side or the GNOME side. Thank you!
> No, that won't, but running this as root should do: > > udevadm trigger --verbose --subsystem-match=input > Thanks, that works well, much better than having to reboot my laptop > OK, that shows that the key codes were assigned correctly. You can also > verify this in "xev", when you press the touchpad enable buttons you should > see some key events showing XF86TouchpadOn/Off. If you only see the "key > press", but not the "key released" event, then you need the > keyboard-force-release rule entry which you already set up; if you still see > "key release" without that (you need to reboot after removing the rule), > then the force-release rule is not necessary. Without the key release rule i can't use my keyboard at all after touching the touch pad toggle button, so i am quite certain that it is required. > Indeed there are no defined Linux key codes for "touchpad off/on/toggle", so > there has been an agreement to interpret F21/22/23 as toggle/on/off: > > http://lists.x.org/archives/xorg/2010-November/051533.html > https://bugs.freedesktop.org/show_bug.cgi?id=31333 Based on this i updated my keymap to: $ cat /lib/udev/keymaps/hewlett-packard-hdx9494nr 0xB2 www # FnF3 0xD8 f23 # touchpad off 0xD9 f22 # touchpad on > So it would be nice if you could check xev whether the problem is on the key > mapping side or the GNOME side. > xev doesn't clearly indicate for me what key i am pressing when i test it, at least it doesn't use the pretty names. In summary, i have updated the keymap file based on the new standard for touch pad toggle values, and the OSD shows up correctly, however nothing is enabling or disabling the touchpad itself. Thanks for your help on this.
I had tried using the f21 toggle key setting when i was retesting this yesterday but it seemed to just disable the touchpad and never re-enable it. But i suspect it may have been a result of not having the key release rule in place. I just updated my kemap file to use f21 for both buttons and it works, the OSD pops up correctly and the touchpad is disabled/re-enabled as needed. Changing the button to f21 vs f22/f23 seems to also remove the need to use the keyboard force release rule. So in summary, here is what i ended up with in order to get this working: $ cat /lib/udev/keymaps/hewlett-packard-hdx9494nr 0xB2 www # FnF3 0xD8 f21 # toggle touchpad off 0xD9 f21 # toggle touchpad on Add the following to the end of the Hewlett-Packard section of /lib/udev/rules.d/95-keymap.rules ENV{DMI_VENDOR}=="Hewlett-Packard", ATTR{[dmi/id]product_name}=="HDX9494NR", RUN+="keymap $name hewlett-packard-hdx9494nr"
I spoke too soon, after rebooting the touch pad no longer toggeled correctly and remained disabled. It appears that the "udevadm trigger --verbose --subsystem-match=input" command does not remove items that no longer match. IE it left the keyboard force release rule in place even after i commented it out. So in addition to everything above, i also have added the following to the end of the Hewlett-Packard section of /lib/udev/rules.d/95-keyboard-force-release.rules: ENV{DMI_VENDOR}=="Hewlett-Packard", ATTR{[dmi/id]product_name}=="HDX9494NR", RUN+="keyboard-force-release.sh $devpath hp-other" The only odditiy is that the touch pad state can get switched sometimes if fedora starts with the touchpad disabled from a hardware standpoint. then the enabled state is opposite of what the OSD indicates. Its not a real issue but it is unfortunate since the hardware is sending a specific keycode to indicate that it is wanting to be enabled or disabled, but in the keymap i have to use the same value of f21 to indicate that the hardware needs to be toggled. would be nice if i could tell it to toggle on (unless it is already on) and toggle off (unless it is already off). Short of that, i think that this is good to go. It survived a reboot and is still working as expected. Is this something that can get added to the udev rules out of the box? I would love for this to finally start working on all new releases!
Another note: the touchpad toggle does not work in the gnome shell activities view. I thought i had seen a note about OSD controls not working in the activities view, but can't find it.
(In reply to comment #8) > I spoke too soon, after rebooting the touch pad no longer toggeled correctly > and remained disabled. It appears that the "udevadm trigger --verbose > --subsystem-match=input" command does not remove items that no longer match. > IE it left the keyboard force release rule in place even after i commented > it out. That's correct, it does not "clear" the mappings as it does not know the original one. > Its not a real > issue but it is unfortunate since the hardware is sending a specific keycode > to indicate that it is wanting to be enabled or disabled, but in the keymap > i have to use the same value of f21 to indicate that the hardware needs to > be toggled. would be nice if i could tell it to toggle on (unless it is > already on) and toggle off (unless it is already off). That's in fact what "touchpad on" (F22) and "touchpad off" (F23) are supposed to do, as toggle means "switch between the two". It seems to be a bug in gnome-settings-daemon that it doesn't handle those properly. So to be honest I'd rather commit your earlier version with F22/F23 and you file another bug against gnome-settings-daemon not handling those correctly? In the meantime you could locally change the rule to move both keys to F21?
For the record, other HPs also use the exact same mapping of 0xD8/D9.
I pushed this to http://cgit.freedesktop.org/systemd/systemd/commit/?id=4dbcb1b3ba Thank you!
(In reply to comment #12) > I pushed this to > http://cgit.freedesktop.org/systemd/systemd/commit/?id=4dbcb1b3ba > > Thank you! It looks like you used the older version of the file before the f21|22|23 standardization from https://bugs.freedesktop.org/show_bug.cgi?id=31333 I think the off and on values need to be switched to what i have in comment #6. Thanks a lot!
(In reply to comment #13) > I think the off and on values need to be switched to what i have in comment > #6. Argh, sorry about that. I pushed that update.
(In reply to comment #14) > (In reply to comment #13) > > > I think the off and on values need to be switched to what i have in comment > > #6. > > Argh, sorry about that. I pushed that update. Brilliant, thank you!
systemd-197-1.fc18.2 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-197-1.fc18.2
Package systemd-197-1.fc18.2: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-197-1.fc18.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-1590/systemd-197-1.fc18.2 then log in and leave karma (feedback).
Package initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing initscripts-9.42.2-1.fc18 systemd-197-1.fc18.2' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-1.fc18,systemd-197-1.fc18.2 then log in and leave karma (feedback).
initscripts-9.42.2-1.fc18, systemd-197-1.fc18.2 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.