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: <AqQUJV3JjFB@christoph>
Date:	23 Nov 2008 23:28:00 +0100
From:	lirc@...telmus.de (Christoph Bartelmus)
To:	jkosina@...e.cz
Cc:	pavel@...e.cz
Subject: Re: In-kernel IR remote control support

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

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ