public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: lirc@bartelmus.de (Christoph Bartelmus)
To: jkosina@suse.cz
Cc: jonsmirl@gmail.com
Cc: jrm8005@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: pavel@suse.cz
Subject: Re: In-kernel IR remote control support
Date: 23 Nov 2008 23:28:00 +0100	[thread overview]
Message-ID: <AqQUJV3JjFB@christoph> (raw)
In-Reply-To: <alpine.LRH.1.10.0811232128050.26670@twin.jikos.cz>

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

  reply	other threads:[~2008-11-23 22:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <7f0c6fc9-556c-41a1-9750-ffb3455589ab@35g2000pry.googlegroups.com>
2008-11-12 23:09 ` In-kernel IR remote control support Christoph Bartelmus
2008-11-13 18:20   ` Maxim Levitsky
2008-11-15 11:58   ` Pavel Machek
2008-11-15 16:10     ` J.R. Mauro
2008-11-23  9:14     ` Christoph Bartelmus
2008-11-23 18:01       ` Pavel Machek
2008-12-02 18:00         ` Christoph Bartelmus
2008-12-03  8:25           ` Pavel Machek
2008-11-23 20:33       ` Jiri Kosina
2008-11-23 22:28         ` Christoph Bartelmus [this message]
2008-11-23 22:58           ` Jon Smirl
2008-12-02 22:00       ` Gerd Hoffmann
2008-12-03  0:59         ` J.R. Mauro
2008-12-03  9:30           ` Gerd Hoffmann
     [not found] <13134331.2018681226657305244.JavaMail.www@wwinf8303>
2008-11-14 17:37 ` Maxim Levitsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AqQUJV3JjFB@christoph \
    --to=lirc@bartelmus.de \
    --cc=jkosina@suse.cz \
    --cc=jonsmirl@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox