On Sun, Oct 25, 2009 at 12:47:03PM +0100, Éric Piel wrote: > Op 23-10-09 18:31, Dmitry Torokhov schreef: >> >> Right, your init scripts/UDEV/HAL whatever adjust keymap to match your >> laptop. > : >> Now, all depends on when this adjustment happens... In your case it >> looks like X server starts before the keymap is adjusted, so on first >> resume the keymaps are different and it disables the device. > Ok, now I catch it. It's actually my own written script, which is > executed at init a bit after X starts. It does a couple of > "setkeycodes". So now the scenario is very clear: X starts, init script > do setkeycodes, resume/suspend, X detect a difference in keymaps and > disable the device. Yep. OK, so X's evdev is still too paranoid but now we know the whole picture and for my part I declare kernel is free from blame ;) > > BTW, I haven't really found info about this: what does setkeycodes? It > does not work on a specific device, but still it changes keymap of some > specific devices. Does it change only the current devices which have > keys? setkeycodes issues KDSETKEYCODE which goes through all devices bound to the "kbd" input handler and sets keycode for the specified scan code for all devices that support that scancode. > Whenever a new input device appears, all the setkeycodes should be > re-executed? > It is recommended to adjust individual devices and HAL has facilities to do that (although now that they deprecating HAL I am not sure what the replacement is). Anyway, for HAL look into: /usr/share/hal/fdi/information/10freedesktop/*-keymap-*.fdi The nice thing here is that keymaps are re-applied if device gets disconnected and rediscovered for one reason or another. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
