linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

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]

Message-ID: <4B1D2109.9090108@redhat.com>
Date:	Mon, 07 Dec 2009 13:36:41 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Jon Smirl <jonsmirl@...il.com>
CC:	Krzysztof Halasa <khc@...waw.pl>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	hermann pitton <hermann-pitton@...or.de>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
	kraxel@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR 	system?

Jon Smirl wrote:
> On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa <khc@...waw.pl> wrote:
>> Once again: how about agreement about the LIRC interface
>> (kernel-userspace) and merging the actual LIRC code first? 

That's fine for me.

>> In-kernel
>> decoding can wait a bit, it doesn't change any kernel-user interface.

This may occur in parallel, but, as we've been discussing, there are
still some needs there that will require kernel-user interfaces.

> I'd like to see a semi-complete design for an in-kernel IR system
> before anything is merged from any source.

There are some tasks there that are independent of any API design.

For example, I'm currently doing some cleanups and improvements 
at the existing IR in-kernel code to create a common IR core that replaces
the already existing feature of handling 7-bits scancode/keycode table to
use the complete scancodes found at the current in-kernel drivers.

This approach works for the current drivers, as none of them currently support
any protocol that requires more than 16 bits for scancodes. However, the
current EVIOGKEYCODE implementation won't scale with bigger scancode spaces.

This code is written to be generic enough to be used by V4L, DVB and LIRC
drivers. So, after having this work done, it should be easy to connect the lirc_dev
to a decoder and to this core support. There are already some in-kernel decoders
that can be used for some protocols, but the better is to review the decoders in
the light of lirc. I expect that the lirc decoders will be in a better shape.

While I'm here, I intend also to create the sysfs bits to create sys/class/irrcv,
as already discussed and submit the patch here for discussions.

Of course, after writing different API's to control the IR tables, we'll
need to improve it, but this depends on the results of the architecture discussions.

Cheers,
Mauro
--
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/