[ltp] Reason for blocking Fn + F5

Henrique de Moraes Holschuh linux-thinkpad@linux-thinkpad.org
Mon, 20 Oct 2008 16:37:37 -0200


On Mon, 20 Oct 2008, Michael Gaber wrote:
> since we're in that hotkey-mask thing already:
> 
> what is the reason for masking Fn + F5 on a T60.

Because of how that key behaves on Windows + ThinkVantage is running, and
because Fn+F5 masking is properly implemented in the firmware (it doesn't
have side-effects when you request control over it).

> the recommended mask is set to 0x008c7fff which prevents the firmware
> from handling Fn+F5 by enabling/disabling Bluetooth.

Yes.  The key issue here is that the firmware behaviour is not the
recommended user behaviour for that key, it is just a "this is the best we
can do in DOS mode" thing.

On the ThinkPad, firmware behaviour for hotkeys means DOS behaviour, not
"intended behaviour".  Now, parts of the DOS behaviour *ARE* intended
behaviour, and the big pain is that for those, IBM didn't implement the
hotkey_mask(!).  That's why you cannot tell the firmware to hands-off the
brightness or volume keys on the T4x, for example.

The ThinkVantage mode of working for Fn+F5 is to launch an application that
lets you set the state of various radios, WLAN included.  It can also be
used as a shortcut to enable/disable all radios instead of opening the GUI.

> this was the way from my first thinkpad (R50p) until some releases ago,
> when i noticed i actually had to change the default mask to get LESS
> acpi-events and MORE firmware-functionality.

Correct.  Not that I care for the ACPI events, these are deprecated.  The
hotkeys generate events on the input device.

> I personally think that it would be useful to let the firmware handle
> everything that it wants, as we already do with Brightness/Thinkligt

Brightness and thinklight are different because they have side-effects.  If
Fn+F5 masking didn't work right, I would have had no choice but to never
enable it by default.

Since I had the choice, its default was made in such a way as to ease
implementing the intended behaviour (defined by the ThinkVantage suite from
IBM/Lenovo).

It is debatable whether it should be issuing KEY_BLUETOOTH instead of
KEY_WLAN, but the deal there is that ThinkVantage doesn't use it as a simple
bluetooth toggle.  I wanted a KEY_<any data radio>, but there is no such
thing (KEY_RADIO is for stuff like a tunner/radio/cd/aux selector in a
remote control).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh