On Tue, Jan 20, 2009 at 5:18 PM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: >> Your assessment of the current situation is correct. Yes, it's a >> pretty annoying situation. It does have the upside that we >> automatically provide the right keycodes for whatever remote comes by >> default with a particular product, but obviously it is a mess if you >> want to use some different remote and if your remote wasn't supported, >> adding support requires a kernel recompile. > > No. Replacing the keycodes is as easy as adding something like this on your > rc.local, or adding an equivalent udev rule: > > ./v4l2-apps/util/keycode /dev/input/event3 ./v4l2-apps/util/keycodes/avertv_303 > > This will replace the keys of the input device (assumed above that the event > device is event3) by the keys at avertv_303 file. > > The in-kernel tables are just the default ones for that device. I guess the thing I disagree with is the notion that what you have described is "easy". * It requires keymaps being maintained both in-kernel and out-of-kernel * It doesn't work with all drivers (like the dib0700) * It doesn't let you select a different in-kernel keymap unless you translate it to a file that can be passed to the keycode utility * The interactions with lircd is inconsistent across drivers. I'm all in favor of some way for making sure the correct default keymap is selected for a given device, but the current approach is pretty haphazard. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
