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]

Date:	Mon, 30 Nov 2009 10:13:46 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Jon Smirl <jonsmirl@...il.com>
CC:	Christoph Bartelmus <christoph@...telmus.de>, 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] What are the goals for the architecture of an in-kernel
 IR 	system?

Jon Smirl wrote:
> On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
> <christoph@...telmus.de> wrote:
>> Hi Mauro,
>>
>> on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
>>> Christoph Bartelmus wrote:
>> [...]
>>>> 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.
>> [...]
>>> I hope it helps for you to better understand how this works.
>> So the plan is to have two ways of using IR in the future which are
>> incompatible to each other, the feature-set of one being a subset of the
>> other?
> 
> Take advantage of the fact that we don't have a twenty year old legacy
> API already in the kernel. Design an IR API that uses current kernel
> systems. Christoph, ignore the code I wrote and make a design proposal
> that addresses these goals...
> 
> 1) Unified input in Linux using evdev. IR is on equal footing with
> mouse and keyboard.

This makes sense to me. Yet, I think that, on some specific cases, we'll
need a raw interface.

> 2) plug and play for basic systems - you only need an external app for scripting

Yes.

> 3) No special tools - use mkdir, echo, cat, shell scripts to build maps

I don't think this is relevant. As we already have ioctls for building maps, and
while all in-kernel drivers can handle scancodes with up to 32 bits, I don't see
any reason to use anything different than what's currently available.

> 4) Use of modern Linux features like sysfs, configfs and udev.

sysfs/udev is a need for hot-plugging. I wouldn't use configfs for it. There aren't
many places using it and afaik some distros are not compiling their kernels with
configfs enabled. Also, as we have already ioctl's for keycode maps, I think
we shouldn't be migrating to controlfs.

> 5) Direct multi-app support - no daemon

For multi-app support usage like your example (e. g. different IR keys mapped into
the same evdev keycode and sent to different applications), I think we should need
a daemon for handling it.

> 6) Hide timing data from user as much as possible.

I agree. Porting the IRQ/gpio pollings to userspace on a system with a high workload
may mean that the keycode will be badly interpreted.

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/