Le mercredi 10 juin 2009 à 17:16 +0200, Michael Meskes a écrit : > Also could you > please try both without running X and preferably without running hal? This > suspiciously looks like the key is interpreted twice with only one being > correct and we need to figure out who's interpreting it incorrectly.
In my opinion, without X it would be difficult to see what's happening. I started X with only a window manager and a terminal to monitor the event in X with xev. So here is what's happening when I don't stop anything: Key volume up: events with keycode 176 Key volume down: events with keycode 160 and keycode 174 Key mute: events with keycode 160 and 241 I think you're right those two last keys must be interpreted twice because X gets two different keycodes when I press those keys... Now I stop hal and here's what happens: Key volume up: events with keycode 176 Key volume down: events with keycode 160 and 174 Key mute: events with keycode 160 and 241 So nothing changed. Now I stop acpid: Key volume up: nothing Key volume down: events with keycode 160 Key mute: events with keycode 241 So I'm pretty sure acpi-support is not at fault for the volume keys. I have absolutely no idea what it could be; I noticed this bug after I upgraded acpi-support but it must have been something else in the upgrade that was related to the keys... Or maybe it was already there by that time and I didn't noticed it before. I've noticed that when I press the volume, mute, and brightness keys I get some output when reading /dev/input/event6. After a bit of testing I've found something interesting: When hal is stopped and I unprobe and probe again sony-laptop then the keys work as expected until I start hal again. So its seems to me that hal is related with the problem. But I think it's weird that stopping hal (invoke-rc.d hal stop) isn't sufficient and that I have to reprobe sony-laptop. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
