linux-kernel - Re: [PATCH 01/18] 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, 12 Sep 2008 00:28:04 +0300
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Gerd Hoffmann <kraxel@...hat.com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jarod Wilson <jwilson@...hat.com>,
	linux-kernel@...r.kernel.org, Jarod Wilson <jarod@...hat.com>,
	Janne Grunau <j@...nau.net>,
	Christoph Bartelmus <lirc@...telmus.de>,
	Mario Limonciello <superm1@...ntu.com>
Subject: Re: [PATCH 01/18] lirc core device driver infrastructure

Gerd Hoffmann wrote:
> Dmitry Torokhov wrote:
>> Couple of questions - what is missing in the current input core to
>> properly support IR devices?
> 
> One issue is *sending* IR codes.
> Another one is access to the raw IR signal (more on this below).
> 
> Probably 90% of the users are happy without that.
> 
>> Could we try to work it in ininput core and
>> maybe provide LIRC device access through an input handler
>> implementation so that applications do not have to implement 2 types of
>> interfaces?
> 
> Not needed.  Applications don't talk to the lirc device directly, they
> talk to the lircd daemon.  The lircd daemon can handle linux input layer
> devices just fine.  So moving drivers from lirc to the input layer can
> be done transparently to the applications.
> 
> Quite some time ago, back the days when I maintained video4linux, I've
> switched the tv card IR drivers from lirc to the input layer.  Main
> reason for that was that having a in-kernel driver using an out-of-tree
> subsystem was a PITA.  I think these days most (all?) TV card drivers
> use the input layer for the IR remotes frequently shipped with those cards.
> 
> 
> Some more background, using the Hauppauge cards as example, which
> usually use rc5 coding with the remotes.
> 
> The older, bt878 based ones do decoding in hardware (i2c chip).  You'll
> get the decoded rc5 keycode.
> 
> The newer, cx88 based ones just sample the raw IR signal and give you
> that.  The decoding has to be done in software.  The driver can program
> the sample rate and has to do the biphase decoding in software to get
> the rc5 keycodes.  The driver gets that done just fine, and the remote
> shipped with the TV card works without problems.
> 
> The part which doesn't work is supporting *any* remote.  The (newer)
> hardware gives you the raw IR signal, so it is possible to decode any IR
> signal in software.  The missing bit is some way to send the raw IR
> samples to userspace (i.e. the lircd daemon) for decoding.  lirc drivers
> do just that.
Hi,

Just my .02 cents,

I personally don't like the lircd daemon (*), I would like to have all input keycodes in
input layer.
What do you, lirc developers think about making lircd a daemon that injects input events via uinput?


(*) the reason I don't like lircd is that not all applications support it.


Best regards,
	Maxim Levitsky

> 
> HTH,
>   Gerd
> --
> 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/

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