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 for Android: free password hash cracker in your pocket

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

Message-ID: <m38wdu7ckz.fsf@intrepid.localdomain>
Date:	Wed, 25 Nov 2009 18:12:44 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	Jarod Wilson <jarod@...sonet.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	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

Maxim Levitsky <maximlevitsky@...il.com> writes:

> There are many protocols,

Few of them really popular.

> There are many receivers, and all have different accuracy.

Receivers? Accuracy? What do you mean exactly?

> Most remotes aren't designed to be used with PC, thus user has to invent
> mapping between buttons and actions.

Of course. You can't change that. Being designed to be used with PC is
not relevant.

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

I have never seen a remote that sends "model" number.
But I admit I only used few universal (including programmable) and few
simple bundled remotes.

> Some don't send anything.

How do they communicate with the receiver?

> There are some weird remotes that send whole packet of data will all
> kind of states.

Of course. This is called "encoding".

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

But their primary function isn't passing keystrokes, is 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.

Why do you think so?
This is less efficient, and more complicated. And would require
incompatible changes to drivers already in the kernel. Keyword:
"regression".

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

Really? You don't know what you're talking about. Forget this idea,
there is absolutely no way to use this without prior configuration. You
can get as far as suggesting default "bundled" model, if there was
something bundled with the receiver of course.

> Then as soon as you press a key, lirc can scan its config database, and
> find a config file to use.

Forget it.

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

This is not a problem. BTW I have nothing against lirc. It can get
keystrokes from input layer. That's the way I use it in fact.
-- 
Krzysztof Halasa
--
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/