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
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad

[Yves-Alexis Perez-2]

On dim., 2009-11-08 at 10:08 +0100, Bjørn Mork wrote:
> 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

It might be X301 specific, because on my T61, using hal 0.5.13-4, Fn+F5
works fine.

Well, in fact I'm remapping Fn+F5 to toggle bluetooth and Fn+F6 to
toggle wlan, with:

cat /etc/hal/fdi/policy/thinkpad-acpi.fdi
<match key="info.product" string="ThinkPad Extra Buttons">
  <append key="input.keymap.data" type="strlist">0x04:bluetooth</append> <!-- Fn+F5 bluetooth -->
  <append key="input.keymap.data" type="strlist">0x05:wlan</append> <!-- Fn+F6 wifi -->
</match>

and it works fine (with rfkill-input loaded, indeed)

Cheers,
--
Yves-Alexis

[Bjørn Mork]

Yves-Alexis Perez <corsac@...> writes:

> On dim., 2009-11-08 at 10:08 +0100, Bjørn Mork wrote:
>> 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
>
> It might be X301 specific, because on my T61, using hal 0.5.13-4, Fn+F5
> works fine.

I got a hint from the hal maintainer to look at
  /usr/share/doc/udev/README.keymap.txt
which I don't have as I'm running the udev from lenny (0.125-7+lenny3 to
be exact).

But that might explain the difference.  Are you using udev from unstable?
Then I guess this is mostly a missing update of the hal dependency on
udev.  The newest version probably requires udev >= 146-?

> Well, in fact I'm remapping Fn+F5 to toggle bluetooth and Fn+F6 to
> toggle wlan, with:
>
> cat /etc/hal/fdi/policy/thinkpad-acpi.fdi
> <match key="info.product" string="ThinkPad Extra Buttons">
>   <append key="input.keymap.data" type="strlist">0x04:bluetooth</append> <!-- Fn+F5 bluetooth -->
>   <append key="input.keymap.data" type="strlist">0x05:wlan</append> <!-- Fn+F6 wifi -->
> </match>
>
> and it works fine (with rfkill-input loaded, indeed)

I don't seem to have rfkill-input anymore, but there is something still
reacting to the rfkill...  That's another change I've been wondering
about:

bjorn@nemi:~$ ls -l /lib/modules/2.6.31-1-amd64/kernel/net/rfkill/
total 44
-rw-r--r-- 1 root root 43997 2009-10-24 20:13 rfkill.ko

It's there in 2.6.30-2-amd64:

bjorn@nemi:~$ ls -l /lib/modules/2.6.30-2-amd64/kernel/net/rfkill/rfkill-input.ko
-rw-r--r-- 1 root root 14001 2009-09-26 00:23 /lib/modules/2.6.30-2-amd64/kernel/net/rfkill/rfkill-input.ko

Are you still using an older kernel, or is my installation missing
something?



Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad

[Yves-Alexis Perez-2]

On dim., 2009-11-08 at 20:35 +0100, Bjørn Mork wrote:

> Yves-Alexis Perez <corsac@...> writes:
> > On dim., 2009-11-08 at 10:08 +0100, Bjørn Mork wrote:
> >> 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
> >
> > It might be X301 specific, because on my T61, using hal 0.5.13-4,
> Fn+F5
> > works fine.
>
> I got a hint from the hal maintainer to look at
>   /usr/share/doc/udev/README.keymap.txt
> which I don't have as I'm running the udev from lenny (0.125-7+lenny3
> to
> be exact).

Uh, then yes, maybe the unconsistent install explains it. I run full
unstable here.

>
> But that might explain the difference.  Are you using udev from
> unstable?
> Then I guess this is mostly a missing update of the hal dependency on
> udev.  The newest version probably requires udev >= 146-?
>
>
> > Well, in fact I'm remapping Fn+F5 to toggle bluetooth and Fn+F6 to
> > toggle wlan, with:
> >
> > cat /etc/hal/fdi/policy/thinkpad-acpi.fdi
> > <match key="info.product" string="ThinkPad Extra Buttons">
> >   <append key="input.keymap.data"
> type="strlist">0x04:bluetooth</append> <!-- Fn+F5 bluetooth -->
> >   <append key="input.keymap.data" type="strlist">0x05:wlan</append>
> <!-- Fn+F6 wifi -->
> > </match>
> >
> > and it works fine (with rfkill-input loaded, indeed)
>
> I don't seem to have rfkill-input anymore, but there is something
> still
> reacting to the rfkill...  That's another change I've been wondering
> about:
>
> bjorn@nemi:~$ ls -l /lib/modules/2.6.31-1-amd64/kernel/net/rfkill/
> total 44
> -rw-r--r-- 1 root root 43997 2009-10-24 20:13 rfkill.ko
>
> It's there in 2.6.30-2-amd64:
>
> bjorn@nemi:~$ ls -l
> /lib/modules/2.6.30-2-amd64/kernel/net/rfkill/rfkill-input.ko
> -rw-r--r-- 1 root root 14001 2009-09-26 00:23
> /lib/modules/2.6.30-2-amd64/kernel/net/rfkill/rfkill-input.ko
>
> Are you still using an older kernel, or is my installation missing
> something?

No, you're right, I don't have any rfkill-input, but I guess rfkill does

the job. Not exactly sure

--
Yves-Alexis

[Yves-Alexis Perez-2]

Yves-Alexis Perez a écrit :

> On dim., 2009-11-08 at 20:35 +0100, Bjørn Mork wrote:
>> Yves-Alexis Perez <corsac@...> writes:
>>> On dim., 2009-11-08 at 10:08 +0100, Bjørn Mork wrote:
>>>> 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
>>> It might be X301 specific, because on my T61, using hal 0.5.13-4,
>> Fn+F5
>>> works fine.
>> I got a hint from the hal maintainer to look at
>>   /usr/share/doc/udev/README.keymap.txt
>> which I don't have as I'm running the udev from lenny (0.125-7+lenny3
>> to
>> be exact).
>
> Uh, then yes, maybe the unconsistent install explains it. I run full
> unstable here.
>> But that might explain the difference.  Are you using udev from
>> unstable?
>> Then I guess this is mostly a missing update of the hal dependency on
>> udev.  The newest version probably requires udev >= 146-?
>>
>>
>>> Well, in fact I'm remapping Fn+F5 to toggle bluetooth and Fn+F6 to
>>> toggle wlan, with:
>>>
>>> cat /etc/hal/fdi/policy/thinkpad-acpi.fdi
>>> <match key="info.product" string="ThinkPad Extra Buttons">
>>>   <append key="input.keymap.data"
>> type="strlist">0x04:bluetooth</append> <!-- Fn+F5 bluetooth -->
>>>   <append key="input.keymap.data" type="strlist">0x05:wlan</append>
>> <!-- Fn+F6 wifi -->
>>> </match>
>>>
>>> and it works fine (with rfkill-input loaded, indeed)
>> I don't seem to have rfkill-input anymore, but there is something
>> still
>> reacting to the rfkill...  That's another change I've been wondering
>> about:
>>
>> bjorn@nemi:~$ ls -l /lib/modules/2.6.31-1-amd64/kernel/net/rfkill/
>> total 44
>> -rw-r--r-- 1 root root 43997 2009-10-24 20:13 rfkill.ko
>>
>> It's there in 2.6.30-2-amd64:
>>
>> bjorn@nemi:~$ ls -l
>> /lib/modules/2.6.30-2-amd64/kernel/net/rfkill/rfkill-input.ko
>> -rw-r--r-- 1 root root 14001 2009-09-26 00:23
>> /lib/modules/2.6.30-2-amd64/kernel/net/rfkill/rfkill-input.ko
>>
>> Are you still using an older kernel, or is my installation missing
>> something?
> No, you're right, I don't have any rfkill-input, but I guess rfkill does
> the job. Not exactly sure
>

Ok, now after some hal-related problem I had to reboot, and now:

- bluetooth is on by default (I already reported that, since quite some
time, but it seems the resolution is stalled :/ )
- Fn+F5 doesn't do anything anymore. I still have the correct fdi file
in hal folders, but when running lshal -m it seems to send a Button
pressed = wlan while I asked it to send bluetooth.

--
Yves-Alexis
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad

[Yves-Alexis Perez-2]

Yves-Alexis Perez a écrit :

> Yves-Alexis Perez a écrit :
>> On dim., 2009-11-08 at 20:35 +0100, Bjørn Mork wrote:
>>> Yves-Alexis Perez <corsac@...> writes:
>>>> On dim., 2009-11-08 at 10:08 +0100, Bjørn Mork wrote:
>>>>> 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
>>>> It might be X301 specific, because on my T61, using hal 0.5.13-4,
>>> Fn+F5
>>>> works fine.
>>> I got a hint from the hal maintainer to look at
>>>   /usr/share/doc/udev/README.keymap.txt
>>> which I don't have as I'm running the udev from lenny (0.125-7+lenny3
>>> to
>>> be exact).
>> Uh, then yes, maybe the unconsistent install explains it. I run full
>> unstable here.
>>> But that might explain the difference.  Are you using udev from
>>> unstable?
>>> Then I guess this is mostly a missing update of the hal dependency on
>>> udev.  The newest version probably requires udev >= 146-?
>>>
>>>
>>>> Well, in fact I'm remapping Fn+F5 to toggle bluetooth and Fn+F6 to
>>>> toggle wlan, with:
>>>>
>>>> cat /etc/hal/fdi/policy/thinkpad-acpi.fdi
>>>> <match key="info.product" string="ThinkPad Extra Buttons">
>>>>   <append key="input.keymap.data"
>>> type="strlist">0x04:bluetooth</append> <!-- Fn+F5 bluetooth -->
>>>>   <append key="input.keymap.data" type="strlist">0x05:wlan</append>
>>> <!-- Fn+F6 wifi -->
>>>> </match>
>>>>
>>>> and it works fine (with rfkill-input loaded, indeed)
>>> I don't seem to have rfkill-input anymore, but there is something
>>> still
>>> reacting to the rfkill...  That's another change I've been wondering
>>> about:
>>>
>>> bjorn@nemi:~$ ls -l /lib/modules/2.6.31-1-amd64/kernel/net/rfkill/
>>> total 44
>>> -rw-r--r-- 1 root root 43997 2009-10-24 20:13 rfkill.ko
>>>
>>> It's there in 2.6.30-2-amd64:
>>>
>>> bjorn@nemi:~$ ls -l
>>> /lib/modules/2.6.30-2-amd64/kernel/net/rfkill/rfkill-input.ko
>>> -rw-r--r-- 1 root root 14001 2009-09-26 00:23
>>> /lib/modules/2.6.30-2-amd64/kernel/net/rfkill/rfkill-input.ko
>>>
>>> Are you still using an older kernel, or is my installation missing
>>> something?
>> No, you're right, I don't have any rfkill-input, but I guess rfkill does
>> the job. Not exactly sure
>>
>
> Ok, now after some hal-related problem I had to reboot, and now:
>
> - bluetooth is on by default (I already reported that, since quite some
> time, but it seems the resolution is stalled :/ )
> - Fn+F5 doesn't do anything anymore. I still have the correct fdi file
> in hal folders, but when running lshal -m it seems to send a Button
> pressed = wlan while I asked it to send bluetooth.
>

Ok, after looking at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555050 it seems that
now you have to do the remapping in udev instead of hal.

Which means:
- do the job again;
- no more xml, yeah!;
- can't put stuff in /etc to override /lib, you have to do that in /lib,
which sucks

Basically, I edited /lib/udev/keymaps/module-lenovo, replaced 0x04 wlan
by 0x04 bluetooth, added 0x05 wlan and saved. Then you have to modprobe
-r thinkpad-acpi and modprobe thinkpad-acpi and it seems to work fine here.

Cheers,
--
Yves-Alexis
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad

[Bjørn Mork]

Yves-Alexis Perez <corsac@...> writes:

> Ok, after looking at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555050 it seems that
> now you have to do the remapping in udev instead of hal.
>
> Which means:
> - do the job again;
> - no more xml, yeah!;
> - can't put stuff in /etc to override /lib, you have to do that in /lib,
> which sucks
>
> Basically, I edited /lib/udev/keymaps/module-lenovo, replaced 0x04 wlan
> by 0x04 bluetooth, added 0x05 wlan and saved. Then you have to modprobe
> -r thinkpad-acpi and modprobe thinkpad-acpi and it seems to work fine here.

You can still do this in /etc.  There just aren't any default hooks, so
you'll have to create your own.

What I did was copy the parts I needed from
/lib/udev/rules.d/95-keymap.rules to
/etc/udev/rules.d/99-late-local.rules

and change them like this (notice the /etc/udev/keymaps path):

 # this part is taken from /lib/udev/rules.d/95-keymap.rules
 ACTION!="add", GOTO="keyboard_end"
 SUBSYSTEM!="input", GOTO="keyboard_end"
 KERNEL!="event*", GOTO="keyboard_end"
 
 ENV{DMI_VENDOR}="$attr{[dmi/id]sys_vendor}"
 ENV{DMI_VENDOR}=="", GOTO="keyboard_end"
 
 ENV{DMI_VENDOR}=="LENOVO*", KERNELS=="input*", ATTRS{name}=="ThinkPad Extra Buttons", RUN+="keymap $name /etc/udev/keymaps/module-lenovo"
 
 LABEL="keyboard_end"



This makes udev first load the default /lib/udev/keymaps/module-lenovo
and then my modified /etc/udev/keymaps/module-lenovo, enabling me to put
only my local changes into the latter:

 bjorn@nemi:~$ cat /etc/udev/keymaps/module-lenovo
 # local overrides
 0x4 bluetooth # Fn+F5


Note that udev process the rule files in lexical order independent of
which directory they are found, ref udev(7).  This makes it easy to do
local overrides.

Another useful udev feature is that duplicate file names are ignored,
and /etc/udev has precedence over /lib/udev in case of ducplicates.
I.e., you could copy /lib/udev/rules.d/95-keymap.rules to
/etc/udev/rules.d/95-keymap.rules and modify it there.


I do believe the change from hal to udev(-extras) is the way to go.,
hopefully getting rid of hal without copying all the bloat - please help
the udev maintainers with that!  But the transition could be handled
more seemlessly.  It should be possible to provide udev/keymaps hooks in
/etc and write a migration script, attempting to keep any local hal
configurations.

But that's easy to say.  One could also ask why I don't just provide a
patch...



Bjørn
--
The linux-thinkpad mailing list home page is at:
http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad