linux-kernel - Re: In-kernel IR remote control support

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: <491C6FE6.6000601@gmail.com>
Date:	Thu, 13 Nov 2008 20:20:22 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Christoph Bartelmus <lirc@...telmus.de>
CC:	linux-kernel@...r.kernel.org, jonsmirl@...il.com, jrm8005@...il.com
Subject: Re: In-kernel IR remote control support

Christoph Bartelmus wrote:
> Hi,
> 
> on 12 Nov 08 at 14:39, J.R. Mauro wrote:
> [...]
>> On Wed, Nov 5, 2008 at 3:07 PM, Jon Smirl <jonsm...@...il.com> wrote:
>>> On Wed, Nov 5, 2008 at 2:59 PM, J.R. Mauro <jrm8...@...il.com> wrote:
>>>> On Wed, Nov 5, 2008 at 2:47 PM, Jon Smirl <jonsm...@...il.com> wrote:
>>>>> New release of in-kernel IR support implementing evdev support. The goal
>>>>> of in-kernel IR is to integrate IR events into the evdev input event
>>>>> queue and maintain ordering of events from all input devices. Still
>>>>> looking for help with this project.
> 
>>>> (Forgive me if this has already been asked or dealt with)
> 
>>>> Have you contacted the LIRC developers? Is there any overlap between
>>>> your projects?
> 
>>> The LIRC people know about this. Pieces of the code are coming from
>>> the LIRC source base and being reworked for kernel inclusion.
> 
>> Great, it's nice to see there's cooperation.
> 
> LOL. There's just a small omission from Jon's side...
> Yes, LIRC people know about this. And Jon has a no-go from me.
> 
> Decoding IR protocols in-kernel is the wrong way IMHO and this will not be  
> supported by LIRC as long as I maintain LIRC.
> It's simply not possible to decode all existing IR protocols and LIRC just  
> stores the timing data for these protocols as-is without trying to decode  
> them. With the in-kernel decoding approach these remotes cannot be  
> supported. I'm not willing to sacrifice the support for these even though  
> they only consist of a very small fraction of remotes in use.
+1 

I agree completely.
This way we can make lirc to recognize any remote.

Don't yet have a general receiver, but when I have one, I would like to use my remotes,
and who knows what protocols they use...


Best solution is to make new input layer message, a raw PCM data.
or, you can even keep the daemon, but make it inject input events back to input system.

The only think I don't like at all about lirc is that you need special library to talk to it
while I want remotes to be used as a keyboards.

Btw, one can write a lirc client that does the above, but this is hackish.

Some standard ir protocols can be decoded in kernel, but there should be standard (not debug) way
to do so in userspace.

Just my .02 cents,

Best regards,
	Maxim Levitsky

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