From: Dmitry Torokhov <dmitry.torokhov@gmail.com> To: "Éric Piel" <Eric.Piel@tremplin-utc.net> Cc: Greg KH <gregkh@suse.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-input@vger.kernel.org" <linux-input@vger.kernel.org> Subject: Re: [REGRESSION] "bind" a device to a driver doesn't not work anymore Date: Sun, 25 Oct 2009 12:07:26 -0700 [thread overview] Message-ID: <20091025190726.GA20932@core.coreip.homeip.net> (raw) In-Reply-To: <4AE43AB7.8070601@tremplin-utc.net> 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
WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Torokhov <dmitry.torokhov@gmail.com> To: "Éric Piel" <Eric.Piel@tremplin-utc.net> Cc: Greg KH <gregkh@suse.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-input@vger.kernel.org" <linux-input@vger.kernel.org> Subject: Re: [REGRESSION] "bind" a device to a driver doesn't not work anymore Date: Sun, 25 Oct 2009 12:07:26 -0700 [thread overview] Message-ID: <20091025190726.GA20932@core.coreip.homeip.net> (raw) In-Reply-To: <4AE43AB7.8070601@tremplin-utc.net> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-10-25 19:07 UTC|newest] Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-10-14 2:05 [REGRESSION] "bind" a device to a driver doesn't not work anymore Dmitry Torokhov 2009-10-14 2:05 ` Dmitry Torokhov 2009-10-15 17:24 ` Éric Piel 2009-10-15 18:13 ` Dmitry Torokhov 2009-10-15 18:13 ` Dmitry Torokhov 2009-10-15 18:27 ` Dmitry Torokhov 2009-10-15 18:27 ` Dmitry Torokhov 2009-10-15 19:32 ` Éric Piel 2009-10-15 19:51 ` Dmitry Torokhov 2009-10-15 19:51 ` Dmitry Torokhov 2009-10-15 21:33 ` Éric Piel 2009-10-15 21:59 ` Dmitry Torokhov 2009-10-15 21:59 ` Dmitry Torokhov 2009-10-15 22:44 ` Éric Piel 2009-10-21 19:34 ` Éric Piel 2009-10-21 20:20 ` Dmitry Torokhov 2009-10-21 20:20 ` Dmitry Torokhov 2009-10-22 16:10 ` Éric Piel 2009-10-22 16:22 ` Dmitry Torokhov 2009-10-22 16:22 ` Dmitry Torokhov 2009-10-22 17:48 ` Éric Piel 2009-10-22 17:48 ` Éric Piel 2009-10-22 18:19 ` Dmitry Torokhov 2009-10-22 18:19 ` Dmitry Torokhov 2009-10-22 18:32 ` Dmitry Torokhov 2009-10-22 18:32 ` Dmitry Torokhov 2009-10-23 8:08 ` Éric Piel 2009-10-23 8:58 ` Dmitry Torokhov 2009-10-23 8:58 ` Dmitry Torokhov 2009-10-23 9:21 ` Éric Piel 2009-10-23 9:21 ` Éric Piel 2009-10-23 16:31 ` Dmitry Torokhov 2009-10-23 16:31 ` Dmitry Torokhov 2009-10-25 11:47 ` Éric Piel 2009-10-25 19:07 ` Dmitry Torokhov [this message] 2009-10-25 19:07 ` Dmitry Torokhov -- strict thread matches above, loose matches on Subject: below -- 2009-10-11 0:04 Éric Piel 2009-10-11 3:00 ` Greg KH 2009-10-12 4:35 ` Dmitry Torokhov 2009-10-12 11:46 ` Éric Piel 2009-10-12 14:44 ` Greg KH 2009-10-12 14:44 ` Greg KH 2009-10-12 15:45 ` Dmitry Torokhov 2009-10-12 15:45 ` Dmitry Torokhov 2009-10-12 17:37 ` Greg KH 2009-10-12 17:37 ` Greg KH 2009-10-12 15:48 ` Dmitry Torokhov 2009-10-12 16:48 ` Éric Piel 2009-10-12 16:48 ` Éric Piel 2009-10-12 17:35 ` Greg KH 2009-10-12 18:33 ` Dmitry Torokhov 2009-10-12 18:54 ` Greg KH 2009-10-12 19:20 ` Dmitry Torokhov 2009-10-12 19:58 ` Greg KH 2009-10-13 3:17 ` Dmitry Torokhov 2009-10-18 7:51 ` Dmitry Torokhov 2009-10-18 8:02 ` Greg KH 2009-10-23 2:01 ` Dmitry Torokhov 2009-10-26 20:59 ` Greg KH 2009-10-26 21:34 ` Dmitry Torokhov 2009-10-26 23:59 ` Greg KH 2009-10-27 16:16 ` Dmitry Torokhov 2009-10-13 9:52 ` Éric Piel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20091025190726.GA20932@core.coreip.homeip.net \ --to=dmitry.torokhov@gmail.com \ --cc=Eric.Piel@tremplin-utc.net \ --cc=gregkh@suse.de \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.