[ltp] Fn+F5 woes again

[Bjørn Mork]

This is Debian specific, but I need to let some frustations out before
filing a bug.  Again...

Due to great help from Henrique and others in this forum, I've had Fn+F5
working the way I want it to for some time now (toggling bluetooth on
and off).  But it stops working with the Debian hal version 0.5.13-4,
and I can't find a way to get it working again except by downgrading to
0.5.13-3


This is how things look with 0.5.13-4:


I have customized the ThinkPad Extra Buttons keymap so that it shows
'0x04:bluetooth' instead of '0x04:wlan' or '0x04:radio':


bjorn@nemi:~$ lshal -u /org/freedesktop/Hal/devices/computer_logicaldev_input_4
udi = '/org/freedesktop/Hal/devices/computer_logicaldev_input_4'
  button.has_state = true  (bool)
  button.state.value = true  (bool)
  button.type = 'radio'  (string)
  info.addons.singleton = {'hald-addon-input'} (string list)
  info.callouts.add = {'debian-setup-keyboard'} (string list)
  info.capabilities = {'input', 'input.keys', 'input.switch', 'button', 'input.keymap'} (string list)
  info.category = 'input'  (string)
  info.parent = '/org/freedesktop/Hal/devices/computer'  (string)
  info.product = 'ThinkPad Extra Buttons'  (string)
  info.subsystem = 'input'  (string)
  info.udi = '/org/freedesktop/Hal/devices/computer_logicaldev_input_4'  (string)
  input.device = '/dev/input/event6'  (string)
  input.keymap.data = {'0x01:screenlock', '0x02:battery', '0x03:sleep', '0x06:switchvideomode', '0x07:f22', '0x08:f24', '0x0b:suspend', '0x0f:brightnessup', '0x10:brightnessdown', '0x11:kbdillumtoggle', '0x13:zoom', '0x14:volumeup', '0x15:volumedown', '0x16:mute', '0x17:prog1', '0x04:bluetooth'} (string list)
  input.product = 'ThinkPad Extra Buttons'  (string)
  input.x11_driver = 'evdev'  (string)
  input.xkb.layout = 'no'  (string)
  input.xkb.model = 'pc105'  (string)
  input.xkb.options = 'lv3:ralt_switch,compose:menu'  (string)
  linux.device_file = '/dev/input/event6'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'input'  (string)
  linux.sysfs_path = '/sys/devices/virtual/input/input6/event6'  (string)


I have four (which is one bluetooth too much...) rfkill devices:

nemi:/tmp# cat /sys/class/rfkill/rfkill?/name
tpacpi_bluetooth_sw
tpacpi_wwan_sw
phy0
hci0
nemi:/tmp# cat /sys/class/rfkill/rfkill?/state
1
1
1
1


Pressing Fn+F5 gives me the (unexpected given the keymap above) result:

nemi:/tmp# input-events 6
/dev/input/event6
   bustype : BUS_HOST
   vendor  : 0x17aa
   product : 0x5054
   version : 16641
   name    : "ThinkPad Extra Buttons"
   phys    : "thinkpad_acpi/input0"
   bits ev : EV_SYN EV_KEY EV_MSC EV_SW

waiting for events
09:15:38.438055: EV_KEY KEY_WLAN pressed
09:15:38.438077: EV_SYN code=0 value=0
09:15:38.438083: EV_KEY KEY_WLAN released
09:15:38.438088: EV_SYN code=0 value=0
^C


This again, triggers an udev event disabling my wlan device (which is to
be expected, given the key event):

Nov  8 09:14:03 nemi hald[7091]: 09:14:03.485 [D] hald_dbus.c:3197: udi=/org/freedesktop/Hal/devices/computer_logicaldev_input_4
Nov  8 09:14:03 nemi hald[7091]: 09:14:03.487 [I] osspec.c:251: SEQNUM=1696, ACTION=change, SUBSYSTEM=rfkill, DEVPATH=/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill2, DEVNAME=, IFINDEX=0
Nov  8 09:14:03 nemi hald[7091]: 09:14:03.487 [I] hotplug.c:435: checking event /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill2
Nov  8 09:14:03 nemi hald[7091]: 09:14:03.487 [I] hotplug.c:121: /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy0/rfkill2 is a device (store)
Nov  8 09:14:03 nemi hald[7091]: 09:14:03.487 [I] device.c:5035: refresh_dev: subsys=rfkill
Nov  8 09:14:03 nemi hald[7091]: 09:14:03.488 [D] hotplug.c:453: events queued = 0, events in progress = 0
Nov  8 09:14:03 nemi hald[7091]: 09:14:03.488 [D] hotplug.c:458: Hotplug-queue empty now ... no hotplug events in progress


nemi:/tmp# cat /sys/class/rfkill/rfkill?/state
1
1
0
1


I have tried to restart hal, just to make sure that hald-addon-input is
using the shown configuration, and I have tried mapping the key to
another value just to eliminate the possibility of hal doing something
magiv with the KEY_BLUETOOTH value.  No difference. Fn+F5 still
generates a KEY_WLAN event and nothing else.  Seems to be hardcoded
somewhere.  But where?

Downgrading to Debian hal 0.5.13-3 makes everything work again, so I
guess what I need to do is open a new Debian bug.  But I'm starting to
get more than just a bit pissed off by this.  If I were allowed to
remove hal, I would have done so a long time ago.  But unfortunately, I
can't do that without removing X (and if anyone wonder why I use hal
from Debian unstable - that's the same reason.  The X301 need a newer
X-server than the one in Debian stable, and the newer X-server requires
hal from unstable).

How difficult can it be understanding that users would rather be able to
configure their system to work 100%, than having "magic" do it 87%
correct?

Arrrgh! Thanks for listening.



Bjørn