On Thu, Aug 27, 2009 at 09:36:36PM +0300, Ville Syrjälä wrote: > On Thu, Aug 27, 2009 at 04:57:10AM -0300, Mauro Carvalho Chehab wrote: > > After years of analyzing the existing code and receiving/merging patches > > related to IR, and taking a looking at the current scenario, it is clear to me > > that something need to be done, in order to have some standard way to map and > > to give precise key meanings for each used media keycode found on > > include/linux/input.h. > > > > Just as an example, I've parsed the bigger keymap file we have > > (linux/media/common/ir-common.c). Most IR's have less than 40 keys, most are > > common between several different models. Yet, we've got almost 500 different > > mappings there (and I removed from my parser all the "obvious" keys that there > > weren't any comment about what is labeled for that key on the IR). > > > > The same key name is mapped differently, depending only at the wish of the > > patch author, as shown at: > > > > http://linuxtv.org/wiki/index.php/Ir-common.c > > > > It doesn't come by surprise, but currently, almost all media player > > applications don't care to properly map all those keys. > > > > I've tried to find comments and/or descriptions about each media keys defined > > at input.h without success. Just a few keys are commented at the file itself. > > (or maybe I've just seek them at the wrong places). > > > > So, I took the initiative of doing a proposition for standardizing those keys > > at: > > > > http://linuxtv.org/wiki/index.php/Proposal > > I welcome this effort. It would be nice to have some kind of consistent > behaviour between devices. But just limiting the effort to IR devices > doesn't make sense. It shouldn't matter how the device is connected. > > FASTWORWARD,REWIND,FORWARD and BACK aren't very clear. To me it would > make most sense if FASTFORWARD and REWIND were paired and FORWARD and > BACK were paired. I actually have those two a bit confused in > ati_remote2 too where I used FASTFORWARD and BACK. I suppose it should > be REWIND instead. > > Also I should probably use ZOOM for the maximize/restore button (it's > FRONT now), and maybe SETUP instead of ENTER for another. It has a > picture of a checkbox, Windows software apparently shows a setup menu > when it's pressed. > > There are also a couple of buttons where no keycode really seems to > match. One is the mouse button drag. I suppose I could implement the > drag lock feature in the driver but I'm not sure if that's a good idea. > It would make that button special and unmappable. Currently I have that > mapped to EDIT IIRC. Unmappable keys should probably emit KEY_UNKNOWN. When I last talked with Richard Hughes there was an idea that userspace may detect KEY_UNKNOWN and alert user that key needs to be mapped since it lacks standard assignment. EV_MSC/MSC_SCAN was supposed to aid in fuguring out what key it was so that usersoace can issue proper EVIOCSKEYCODE... > > The other oddball button has a picture of a stopwatch (I think, it's > not very clear). Currently it uses COFFEE, but maybe TIMER or something > like that should be added. The Windows software's manual just say it > toggles TV-on-demand, but I have no idea what that actually is. > I'd start by looking at HID usage tables and borrowing [missing] definitions from there. Patches commenting on intended use of input keycodes are always welcome. -- 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
