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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 Nov 2009 18:54:37 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Krzysztof Halasa <khc@...waw.pl>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Jarod Wilson <jarod@...hat.com>, linux-kernel@...r.kernel.org,
	Mario Limonciello <superm1@...ntu.com>,
	linux-input@...r.kernel.org, linux-media@...r.kernel.org,
	Janne Grunau <j@...nau.net>,
	Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was:
	Re: [PATCH 1/3 v2] lirc core device driver infrastructure

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@...hat.com> escreveu:
> 
> > Krzysztof Halasa wrote:
> > > Mauro Carvalho Chehab <mchehab@...hat.com> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/