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:	Fri, 27 Nov 2009 03:50:13 +0100
From:	hermann pitton <hermann-pitton@...or.de>
To:	Trent Piepho <xyzzy@...akeasy.org>
Cc:	Mauro Carvalho Chehab <mchehab@...hat.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Jarod Wilson <jarod@...hat.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.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: [RFC] Should we create a raw input interface for IR's ? - Was:
	Re: [PATCH 1/3 v2] lirc core device driver infrastructure


Am Donnerstag, den 26.11.2009, 14:59 -0800 schrieb Trent Piepho:
> On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote:
> > >> See above. Also, several protocols have a way to check if a keystroke were
> > >> properly received. When handling just one protocol, we can use this to double
> > >> check the key. However, on a multiprotocol mode, we'll need to disable this
> > >> feature.
> > >
> > > I don't think so. We can pass the space/mark data to all (configured,
> > > i.e. with active mapping) protocol handlers at once. Should a check
> > > fail, we ignore the data. Perhaps another protocol will make some sense
> > > out of it.
> >
> > What happens if it succeeds on two protocol handlers?
> 
> Then you use the protocol that fits best.  For instance decoding with one
> protocol might produce a scancode that isn't assigned to any key, while
> another protocol produces an assigned scancode.  Clearly then the latter is
> most likely to be correct.  It also possible to have a space/mark length
> that is within the allowable tolerances for one remote, but is even closer
> another remote.  You don't want to just find *a* match, you want to find
> the *best* match.
> 
> The in kernel code in v4l is very simple in that it is only designed to
> work with one procotol and one remote.  Once you have multiple remotes of
> any type things become much more complicted.  Keep in mind that remotes
> that aren't even intended to be used with the computer but are used in the
> same room will still be received by the receiver.  It's not enough to
> decode the signals you expect to receive, you must also not get confused by
> random signals destined for somewhere else.

Giving some random living room these days, likely open to the kids
rooms, you have to take that into account.

Another point, if decoding from IRQs generated by the remote, there is
flawed hardware around, needing to poll IRQs in some timely manner to
get it to something at all.

This will break such remotes. Never seen?

For me the first priority is, that existing remotes are not broken.

Don't tell you have done a nice job just now, but are unfortunately in
need of testers ... 

Cheers,
Hermann


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