Bug 128088

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. ***

*** Bug 170594 has been marked as a duplicate of this bug. ***