2
Quick update on the last post: the Thinkpad special keys are not all working. Basically, the ones that do work are the ones the are *directly* connected to the hardware: the Thinklight key, the volume keys, etc... The Fn+Fxx keys that are emulated via the X server have no effect, for instance the ones related to the screen brightness or the Fn+F2 to lock the session.
Taking the example of the brightness control keys, they appear configured in the X server mapping:
[nicolas@munin ~]$ xmodmap -pk|grep XF86MonBrightness
232 0x1008ff03 (XF86MonBrightnessDown) (...)
233 0x1008ff02 (XF86MonBrightnessUp) (...)
Experimenting with xev, it appears that the signals sent via the keys are indeed captured, i.e. the X server is aware that the special keys have been pressed and that the laptop should adjust the screen brightness accordingly... but still, nothing happens.
At the end of the day, the problem appears related to the way KDE interfaces with HAL (modern distros like Fedora 10 rely on it to configure the kernel input devices. Xorg in turn gets these key events through the evdev driver and will no longer try to take control of the input devices away from the kernel - NDLR).
Googling around, several bugs exists on various conbinations of KDE/kernel... but the good news is that the issue does not occur with GNOME. I've tested it with a Live Fedora distro, just to be sure, then opted to un-install KDE / install GNOME.
Taking the example of the brightness control keys, they appear configured in the X server mapping:
[nicolas@munin ~]$ xmodmap -pk|grep XF86MonBrightness
232 0x1008ff03 (XF86MonBrightnessDown) (...)
233 0x1008ff02 (XF86MonBrightnessUp) (...)
Experimenting with xev, it appears that the signals sent via the keys are indeed captured, i.e. the X server is aware that the special keys have been pressed and that the laptop should adjust the screen brightness accordingly... but still, nothing happens.
At the end of the day, the problem appears related to the way KDE interfaces with HAL (modern distros like Fedora 10 rely on it to configure the kernel input devices. Xorg in turn gets these key events through the evdev driver and will no longer try to take control of the input devices away from the kernel - NDLR).
Googling around, several bugs exists on various conbinations of KDE/kernel... but the good news is that the issue does not occur with GNOME. I've tested it with a Live Fedora distro, just to be sure, then opted to un-install KDE / install GNOME.
Post a Comment