On Sat, Nov 28, 2009 at 12:39:18AM -0200, Mauro Carvalho Chehab wrote: > Em Thu, 26 Nov 2009 17:06:03 -0200 > Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> escreveu: > > > Krzysztof Halasa wrote: > > > Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> writes: > > > > > >> Technically, it is not hard to port this solution to the other > > >> drivers, but the issue is that we don't have all those IR's to know > > >> what is the complete scancode that each key produces. So, the hardest > > >> part is to find a way for doing it without causing regressions, and to > > >> find a group of people that will help testing the new way. > > > > > > We don't want to "port it" to other drivers. We need to have a common > > > module which does all RCx decoding. The individual drivers should be as > > > simple as possible, something that I outlined in a previous mail. > > > > With the current 7bits mask applied to almost all devices, it is probably not very > > useful for those who want to use generic IRs. We really need to port the solution > > we've done on dvb-usb to the other drivers, allowing them to have the entire > > scancode at the tables while keep supporting table replacement. > > > > The issue is that we currently have only 7bits of the scan codes produced by the IR's. > > So, we need to re-generate the keycode tables for each IR after the changes got applied. > > Ok, I got some time to add support for tables with the full scan codes at the V4L drivers. > In order to not break all tables, I've confined the changes to just one device (HVR-950, > at the em28xx driver). The patches were already committed at the -hg development tree. > > In order to support tables with the full scan codes, all that is needed is to add the > RC5 address + RC5 data when calling ir_input_keydown. So, the change is as simple as: > > - ir_input_keydown(ir->input, &ir->ir, > - poll_result.rc_data[0]); > + ir_input_keydown(ir->input, &ir->ir, > + poll_result.rc_address << 8 | > + poll_result.rc_data[0]); > + else > > An example of such patch can be seen at: > http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56 > > There are still some work to do, since, currently, the drivers will use a table with a fixed > size. So, you can replace the current values, but it is not possible to add new keys. > > The fix for it is simple, but we need to think what would be the better way for it. There are > two alternatives: > - A table with a fixed size (like 128 or 256 entries - maybe a modprobe parameter > could be used to change its size); > - some way to increase/reduce the table size. In this case, we'll likely need some > ioctl for it. > Hmm, why can't you just resize it when you get EVIOCSKEYCODE for scancode that would be out of bounds for the current table (if using table approach)? -- Dmitry -- 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