On Wednesday 30 May 2007 20:53, Henrique de Moraes Holschuh wrote: > On Wed, 30 May 2007, Dmitry Torokhov wrote: > > On 5/30/07, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > > >It is trivial to guarantee that KEY_PROG is unique for a single input > > >device (keyboard), but it certainly won't work across multiple devices. > > >Userspace has to know what kind of input device it is talking to to map > > >them to something, but since the input layer already provides this > > >information, I was not going to raise a fuss about it. I figure it is > > >the price of not increasing even more the keycode table. > > > > Actually I try to discourage people from using input_id during device > > discovery but rather tell them to analyze capability bits and then decide > > if their application is interested in that particular input device. I > > think input_id should pretty much only used by udev & co. to adjust > > default kernel setup for the needs of local installation (fix keymap, > > adjust absmax, etc). > > It is likely going to be used by something like udev, or an init script, or > a thinkpad-configurator helper, or whatever. Sounds like the sort of stuff > that should be paying attention to input_id anyway. Right. > > We don't appear to have deployed a good kernel-userland interface that > allows us to have generic "press an unknown key and tell me what you want it > to do" application in userland, but if we do please correct me. If > KEY_UNKNOWN was always required to send a EV_MSC MSC_RAW/MSC_SCAN, then we > would have one. > Yes, I think this is a resonable requrement. > Maybe we can add that requirement and driver changes (if any, for all I know > most drivers might already be generating such events) for 2.6.23? I think that we should start with drivers that allow adjusting keymaps via EVIOCGKEYCODE/EVIOCSKEYCODE. If driver does not allow changing keymap then it does not really matter (although I will try to convert drivers now that we have getkeycode/setkeycode per-device methods). > I bet > Richard would like that one a lot. Richard? > > Such functionality makes most of my requests for new keycodes irrelevant, so > I will just trim that down. > > > >That said, how is one to know which hardware key was translated to > > >KEY_UNKNOWN, so that he can inform the user to remap that key? Should I > > >send another event together with KEY_UNKNOWN that has the raw keycode? > > >Which one? > > > > You may try using EV_MSC/MSC_SCAN. You can even send it all the time, not > > only for KEY_UNKNOWN. > > Will do, thanks. And I will send it all the time, that will force people to > properly implement code that can deal with them in userland. > > What is the exact difference between MSC_RAW and MSC_SCAN? Which one can be > used as an index to reprogram the keymap using the IOCTLs? > MSC_RAW is just raw data from device. It may carry make/break data encoded in it. MSC_SCAN is what one need. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
