Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux