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

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

Date:	Sun, 23 Nov 2008 17:58:38 -0500
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Christoph Bartelmus" <lirc@...telmus.de>
Cc:	jkosina@...e.cz, jrm8005@...il.com, linux-kernel@...r.kernel.org,
	pavel@...e.cz
Subject: Re: In-kernel IR remote control support

On Sun, Nov 23, 2008 at 5:28 PM, Christoph Bartelmus <lirc@...telmus.de> wrote:
> Hi,
>
> on 23 Nov 08 at 21:33, Jiri Kosina wrote:
>> On Sun, 23 Nov 2008, Christoph Bartelmus wrote:
>
>>> You can have LIRC setup to decode all common remote control protocols.
>>> It's just a matter of proper packaging and pre-configuration. You don't
>>> have to write a single line of code for this (I still have to add uinput
>>> support, though, which I probably would have done by now, if I weren't
>>> busy writing posts like this).
>
>> Just a question -- how much is the situation different to what we
>> currently have for HID devices?
>>
>> For these, we currently have common code, that is able to handle all the
>> "normal" devices by default, that are fully compliant with the HID
>> standard.
>> For the devices that don't behave that well, we have specialized drivers,
>> that use all the generic HID infrastructure to handle the
>> standard-compliant behavior of the device and allows the specialized
>> drivers to implement only the parts that violate standard.
>>
>> It's pretty lightweight and seems to work well. Wouldn't this work also
>> for LIRC drivers?
>
> No. Unlike with HID devices, with most IR receivers you can use any
> remote. In LIRC we write drivers for the receivers and don't care about
> the remote, which is handled in userspace. The suggested approach would
> move both receiver and remote handling into kernel space (actually only
> part of it because many receivers have userspace drivers, so both receiver
> and remote handling must be done in userspace anyway for these receivers).

Now that I've worked on this for a while, I'm moving towards putting
all of the IR drivers in the kernel. Putting them in the kernel
collects them in a single place where they can't get lost and they
will be maintained on all archs. Sure you can write these drivers in
user space too. But they are so small (10-20K), they are hardly
noticeable in the kernel when compared to a 4MB Nvidia device driver.

I'm also a big fan of using existing kernel interfaces and not
building new ones. Evdev, sysfs and configfs can implement everything
IR needs and all of them are pre-existing APIs.

The code I'm post is not being marked for inclusion in the kernel. It
is being posted RFC - request for comment. Various features aren't
implement (repeat, more protocol engines, etc). There are bugs too.
After I added configfs support I discovered that interrupt handling
needs to be altered since configfs was being called from interrupt
context and that;s not allowed. I'm traveling now and will fix it when
I get back next week.

I'd like to get some input on the general design but so far nobody
have commented on the design.

>
> Christoph
>

-- 
Jon Smirl
jonsmirl@...il.com
--
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/