linux-kernel - Re: IR raw input is not sutable for input 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: <20091126053813.GF23244@core.coreip.homeip.net>
Date:	Wed, 25 Nov 2009 21:38:13 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	Jarod Wilson <jarod@...sonet.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	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: IR raw input is not sutable for input system

On Wed, Nov 25, 2009 at 01:32:51AM +0200, Maxim Levitsky wrote:
> Folks, I really want to tell everyone that doing all the mapping from
> raw codes to keypresses in kernel is wrong.

Why is this wrong? Doing simple translation is easy and it does not
require having all the tables for all possible remotes in the kernel. We
have appropriate interfaces to load keymaps at runtime (for the devices
whose drivers support this feature).

> This idea keeps showing up, because many users think that remotes send
> some universal codes that you can just 'parse' and feed back to input
> system.
>

Well, they send some data that can be parsed and thus fed to whatever we
want to feed it.

 
> Its not the case.
> There are many protocols, I know that by experimenting with my universal
> remote. There are many receivers, and all have different accuracy.
> Most remotes aren't designed to be used with PC, thus user has to invent
> mapping between buttons and actions.
> Its is not possible to identify remotes accurately, many remotes send
> just a 8 bit integer that specifies the 'model' thus many remotes can
> share it.
> Some don't send anything.
> 
> There are some weird remotes that send whole packet of data will all
> kind of states.
> 
> Think about it, video capture device is also an input device, a scanner
> is an input device too, sound card can work as input device too.

You are stretching. There are no button presses involved with sound (not
unless you go all the way down to keys on a piano ;) )

> But we aren't doing any parsing, even we don't support deflating of many
> proprietary and standard video/image encoding formats.
> We let userspace do it.
> 
> Kernel job is to take the information from device and present it to
> userspace using uniform format, that is kernel does 1:1 translating, but
> doesn't parse the data.

Should we return to the times where we had raw PS/2 data streams sent to
userspace, separately from HID and other formats? I don't think it is a
good idea.

> Uniform format doesn't mean kernel always converts to one format, its
> not like sound card always recording in 32 bit 96000 Khz format, even if
> underlying device doesn't support that.
> 
> 
> So, device that decode IR code are presented to userspace as pure input
> devices. I agree that creating fake raw codes from that is bad.
> 
> But devices that send raw data pass it to lirc.
> lirc is well capable to decode it, and its not hard to add
> auto-detection based on existing configuration drivers, so IR devices
> will work with absolutely no configuration.
> All you will have to do is ensure that lirc is installed.
> Then udev can even start it automatically.
> Then as soon as you press a key, lirc can scan its config database, and
> find a config file to use. combine that with a GUI for unknown remotes
> and you get an awesome usability.
> 

Why can't the same be done in kernalspace though?

> Also don't forget that there are pure userspace drivers. They won't have
> access to in-kernel decoder so they will still have to parse protocols,
> so will have code duplication, and will still need lirc thus.
> 
> 
> So why to burden the kernel with protocols, etc..

We do burden it with TCP, shall we take it out?

-- 
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/