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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 26 Nov 2009 14:25:28 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Christoph Bartelmus <lirc@...telmus.de>
CC:	jarod@...sonet.com, awalls@...ix.net, dmitry.torokhov@...il.com,
	j@...nau.net, jarod@...hat.com, khc@...waw.pl,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, superm1@...ntu.com
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was:
 Re: [PATCH 1/3 v2] lirc core device driver infrastructure

Christoph Bartelmus wrote:
> Hi,
> 
> on 25 Nov 09 at 12:44, Jarod Wilson wrote:
> [...]
>> Ah, but the approach I'd take to converting to in-kernel decoding[*] would
>> be this:
> [...]
>> [*] assuming, of course, that it was actually agreed upon that in-kernel
>> decoding was the right way, the only way, all others will be shot on sight.
> 
> I'm happy to see that the discussion is getting along.
> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just  
> because I'm not familiar at all with input layer toolset.
> 
> 1. For sure in-kernel decoding will require some assistance from userspace  
> to load the mapping from IR codes to keys.

Current drivers have the IR keycode tables in-kernel also, directly associated
with the board ID.

> So, if there needs to be a tool  
> in userspace that does some kind of autodetection, why not have a tool  
> that does some autodetection and autoconfigures lircd for the current  
> device.

There are userspace tools to change the IR keycode maps. It shouldn't be hard to
change it to autodetect the hardware and to autoconfigure lircd.

> Lots of code duplication in kernel saved. 

Huh? The code is already there.

> What's the actual benefit of in-kernel decoding?

There are two benefits:

1) the developer that adds the hardware also adds the IR code. He has the hardware
and the IR for testing, so it means a faster development cycle than waiting for someone
else with the same hardware and IR to recode it on some other place. You should
remember that not all developers use lirc;

2) the IR works out of the box.

> 2. What would be the format of the key map? lircd.conf files already exist  
> for a lot of remote controls. Will we have a second incompatible format to  
> map the keys in-kernel? Where are the tools that create the key maps for  
> new remotes?

No matter what tool you use, the format should be very close: scancode -> key_code.

If you wan to take a look on a real example, I'm enclosing the keycode table used by
dib0700 driver, as generated/readed by a simple keycode application I made to test
the dynamic keycode loading:
	http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c

Most of the keycodes there are RC5 keys. There are also some NEC keys,
as those devices can work with either RC5 or NEC keycodes, by using a different
parameter during module load.

In the case of this driver, the pulse/space is done in hardware by the DibCom chip. The
scancode is sent to PC via the USB interface.

I hope it helps for you to better understand how this works.

Cheers,
Mauro.

View attachment "dib0700_rc_keys" of type "text/plain" (3542 bytes)