Bugzilla – Bug 128088
Bluetooth on/off key does not work on IBM T41p after acpid was started
Last modified: 2007-06-05 10:01:16 UTC
For switching on/off the hardware bluetooth functionally I use the Fn+F5 key. This key works as expected during BIOS and while the kernel loads, but is not recognized anymore after acpid was started. Also switching off acpid after it was started once does not help to make the key working again. Instead a reboot is required.
Could this have something to do with the ibm_acpi module, Timo?
Yes, possibly. Robert, could you please test the following two things with acpid being _enabled_: * uncommenting the module options in /etc/modprobe.d/ibm_acpi. Adding a "#" at the beginning of the line should work. Reboot and check if Fn-F5 works as expected. * remove "ibm_acpi" from /var/lib/acpi/laptop_modules. Reboot and check if Fn-F5 works as expected. cc'ing Stefan, he investigating this problem last week if I recall correctly.
On my system (IBM ThinkPad T40p) removing hokey=enabled does help but this gives on regression on another issue (Fn-F12 needs to be reported as hotkey event). I'll try to find a hotkey range which will block Fn-F5 and leaves Fn-F12 untouched.
Created attachment 54210 [details] patch against /etc/modprobe.d/ibm_acpi to fix this issue
Robert, forget comment #2 if this patch helps. If it works, I'll request a SWAMP id for an YaST online update.
Yes, the patch helps, I ttested it with a T41p. Please make a YOU.
*** Bug 118026 has been marked as a duplicate of this bug. ***
aj, we'd need a SWAMP id for this one. Or we could merge this one with other acpid fixes pending. Not sure if there is a SWAMP id for the other issues yet. cc'ing Seife.
AJ is on vacation right now. Harald, can you please take care of this issue?
Update approved. I haven't found another acpid SWAMP ID, so created a new one: Maintenance-Tracker-2666
I've submitted an updated package (already checked-in -- unbelievable fast these days ;-) and put acpid.patch.box to /work/src/done/PATCHINFO . Closing.
released
(In reply to comment #14) > released Since it was fixed, the WLAN on/off key (Fn.+F5) on IBM Thinkpad r52 (TYPE 1860-5EG) doesn't work any longer. Had to change 0xffef back to 0xffff in /etc/modprobe.d/ibm_acpi
Hum. I'm puzzled. Are you saying that * hotkey=enabled,0xffff enables you to switch WLAN with Fn-F5 and respectivly * hotkey=enabled,0xffef does not let you switch WLAN with Fn-F5?
exactly! acpi_listen says "ibm/hotkey HKEY 00000080 00001005" for Fn+F5 if "options ibm_acpi hotkey=enabled,0xffff experimental=1" ist set. My script uses this event to turn off/on the WLAN. if "options ibm_acpi hotkey=enabled,0xffef experimental=1" is set acpi_listen doesn't say anything for Fn+F5... And nothing happens... Fn+F4 e.g. (suspend to disk) is still working and acpi_listen says "ibm/hotkey HKEY 00000080 00001004"
Ah, OK. The problem is severe for users who can not toggle their Bluetooth anylonger since they can not trigger a script: Fn-F5 does some internal magic which makes the Bluethooth device appear/disappear on the USB. I'll leave this one as LATER to think a bit about it.
*** Bug 163591 has been marked as a duplicate of this bug. ***
I have a Thinkpad T43p and I had to make the change mentioned in comment #16 to ffef and now it turns on and off with fn+f5
*** Bug 164877 has been marked as a duplicate of this bug. ***
if 164877 is a duplicate, this cannot be "LATER".
Timo, any news on this one yet?
Well, not really. We're on the horns of a dilemma with issue. Some background: We've had 0xffef for SL10.0 (as a result of bug #128088), we then we're planning to switch to 0xffff for SL10.1/SLE{S,D}10 (as a result of bug #150357). Jared, could you please follow the instructions of comment #13 in bug #150357 and let me know if you get things working with this?
The condition for FnF5 in the thinkpad_acpi_events found in /usr/lib/powersave/scripts is as follows: 4101) HOTKEY="Fn+F5" # Wireles LAN if [ -x /opt/thinkpad/ac/onscreen_ac.sh ] ; then run_on_xserver "/opt/thinkpad/ac/onscreen_ac.sh start" & ACTION="start onscreen_ac applet" elif [ grep -q "status.*disabled" /proc/acpi/ibm/bluetooth ] ; then echo enable > /proc/acpi/ibm/bluetooth ACTION="enable blooetooth" else echo disable > /proc/acpi/ibm/bluetooth ACTION="disable blooetooth" fi Line 103- elif [ grep -q "status.*disabled" /proc/acpi/ibm/bluetooth ] returns false, thus script executes the next else part (which dont have condition). The original script was the following and it works fine. : "'grep status /proc/acpi/ibm/bluetooth | grep -c enabled'" = "0"
(In reply to comment #27) > Line 103- elif [ grep -q "status.*disabled" /proc/acpi/ibm/bluetooth ] i see the bug. The "[" and "]" are wrong, remove them and it will work. Holger, i'll check a fixed version into trunk, can you please test it (i don't have a TP with Bluetooth) and submit a package? Thanks for spotting this nasty thinko of me :-)
Ok, will test it and submit a new package as soon as the fix is in.
Noritoshi, thank you for this! Wonderful that we finally solved this issue.
Package submitted to autobuild.
*** Bug 170594 has been marked as a duplicate of this bug. ***