Bug#555050: hal: Remapping Fn+F5 to anything else than KEY_WLAN does not work
Bjørn Mork
Version: 0.5.13-4
Severity: normal
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I am remapping Fn+F5 on my Thinkpad to '0x04:bluetooth' to have it toggle
BlueTooth on and off instead of the wlan, which I always need on. The
'ThinkPad Extra Buttons' input device with keymap data looks like this:
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)
This stopped working after upgrading to hal 0.5.13-4. No matter what I set the
keymap to, Fn+F5 will always generate KEY_WLAN:
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
I have also tried other values than KEY_BLUETOOTH, just to ensure that it
isn't just some magic related to that value. No difference.
Downgrading to hal 0.5.13-3 fixes the problem, so this is a regression between
those two versions.
And just to make it clear: I do not want to run hal from unstable. This
is a choice forced upon me by an x-server dependency. And the unstable
x-server is unfortunately necessary to support the GM45 IGP in this
laptop.
So downgrading hal to the stable version or removing hal is not possible.
Bjørn
- -- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (700, 'stable'), (600, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages hal depends on:
ii acl 2.2.47-2 Access control list utilities
ii adduser 3.110 add and remove users and groups
ii consolekit 0.3.1-2 framework for defining and trackin
ii dbus 1.2.1-5+lenny1 simple interprocess messaging syst
ii hal-info 20090716-1 Hardware Abstraction Layer - fdi f
ii libblkid1 2.16.1-4 block device id library
ii libc6 2.10.1-5 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.1-5+lenny1 simple interprocess messaging syst
ii libdbus-glib-1-2 0.82-2 simple interprocess messaging syst
ii libexpat1 2.0.1-4+lenny1 XML parsing C library - runtime li
ii libglib2.0-0 2.22.2-2 The GLib library of C routines
ii libhal-storage1 0.5.11-8 Hardware Abstraction Layer - share
ii libhal1 0.5.11-8 Hardware Abstraction Layer - share
ii libpolkit2 0.9-4 library for accessing PolicyKit
ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library
ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip
ii mount 2.13.1.1-1 Tools for mounting and manipulatin
ii pciutils 1:3.0.0-6 Linux PCI Utilities
ii policykit 0.9-4 framework for managing administrat
ii udev 0.125-7+lenny3 /dev/ and hotplug management daemo
ii usbutils 0.73-10 Linux USB utilities
Versions of packages hal recommends:
ii eject 2.1.5+deb1-4 ejects CDs and operates CD-Changer
ii pm-utils 1.1.2.4-1 utilities and scripts for power ma
Versions of packages hal suggests:
pn gnome-device-manager <none> (no description available)
- -- no debconf information
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkr2jjIACgkQ10rqkowbIskyQgCdFsbdPbzIl0X3nFsHwp9tAeiK
k5gAn2fO/CuyGzyhkh+HpilnNMIbpAMu
=wuXF
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Michael Biebl
> Bjørn Mork wrote:
>> Package: hal
>> Version: 0.5.13-4
>> Severity: normal
>>
>
>> keymap to, Fn+F5 will always generate KEY_WLAN:
>
See also /usr/share/doc/udev/README.keymap.txt
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
> Package: hal
> Version: 0.5.13-4
> Severity: normal
>
> This stopped working after upgrading to hal 0.5.13-4. No matter what I set the
> keymap to, Fn+F5 will always generate KEY_WLAN:
Have you read the debian changelog?
Michael
Bjørn Mork
> Michael Biebl wrote:
>> Bjørn Mork wrote:
>>> Package: hal
>>> Version: 0.5.13-4
>>> Severity: normal
>>>
>>> I am remapping Fn+F5 on my Thinkpad to '0x04:bluetooth' to have it toggle
>>
>>> This stopped working after upgrading to hal 0.5.13-4. No matter what I set the
>>> keymap to, Fn+F5 will always generate KEY_WLAN:
>>
>> Have you read the debian changelog?
Yes. I did see the entry
* Disable multimedia key remapping which is managed by udev. Drop build
dependency on gperf.
and wondered whether it might be related. But I decided that if it was,
then
a) it must be unintentional as the Fn+X keys don't have anything to do
with multimedia, and
b) the breakage is unexpected as there is nothing telling me to expect
it
> See also /usr/share/doc/udev/README.keymap.txt
Well, I could be difficult as you got the output from the reportbug
script with my installed versions:
bjorn@nemi:~$ ls -l /usr/share/doc/udev/README*
-rw-r--r-- 1 root root 4056 2008-07-18 16:26 /usr/share/doc/udev/README
-rw-r--r-- 1 root root 3307 2009-08-26 12:26 /usr/share/doc/udev/README.Debian.gz
-rw-r--r-- 1 root root 3093 2009-08-26 12:27 /usr/share/doc/udev/README.vol_id
But I won't. Well, not more than I've been already at least :-)
Thanks for the pointer. I guess I need to update udev as well. But
doesn't that mean that hal should depend on the newer udev version?
Still, I this is the second time this year that bad design changes in
hal breaks a working system for me. I probably don't have to say this,
but I'm not all that impressed by the smoothness of these transistions...
Bjørn
Michael Biebl
>
> Thanks for the pointer. I guess I need to update udev as well. But
> doesn't that mean that hal should depend on the newer udev version?
Probably
>
> Still, I this is the second time this year that bad design changes in
> hal breaks a working system for me.
Well, I wouldn't consider a non working FN+F5 key as "breaking a working system"
but rather an annoyance. But your complaint is noted.
I probably don't have to say this,
> but I'm not all that impressed by the smoothness of these transistions...
It has to be said, that the keyboard mappings in hal-info have been converted to
the new udev format, so if you had those changes upstream in hal-info there
should be no breakage.
I'll bump the udev dependency and probably also add a note in NEWS.Debian with a
reference to /usr/share/doc/udev/README.keymap.txt for people that have local
modifications.