public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Christoph Bartelmus <lirc@bartelmus.de>
Cc: pavel@suse.cz, jonsmirl@gmail.com, jrm8005@gmail.com,
	linux-kernel@vger.kernel.org
Subject: Re: In-kernel IR remote control support
Date: Tue, 02 Dec 2008 23:00:45 +0100	[thread overview]
Message-ID: <4935B00D.5010302@redhat.com> (raw)
In-Reply-To: <AqQThtpZjFB@christoph>

  Hi,

>> Can we merge the common ones into the kernel, while still keeping the
>> obscure ones in userspace using uinput or something?
> 
> Why do you want to complicate things even more.

Reality check please.  It already is that complicated.  We have IR
kernel drivers today.

> The decision to include some IR support using the Linux input layer some  
> time ago has forced *me* to add support for this in LIRC and explain to  
> people why for some devices they need LIRC drivers, and for some they need  
> the kernel drivers, and for other configurations they have to explicitly  
> disable the kernel drivers and replace them by LIRC drivers, etc.

The only way to get out of this situation long-term is to get advanced
IR support into the mainline kernel.

It doesn't matter how that actually looks like.  Could be pretty much
like todays lirc drivers.  Could be some input layer extention for
receiving/sending raw IR codes.  Could be something completely different
such as using the tty layer for that.  That has to be discussed and
agreed on.

What *does* matter is being in mainline.  lirc not being in mainline was
*the* major reason for me to use the input layer to handle TV card IR
support.  Having a in-tree driver depending on a out-of-tree subsystem
for IR is a major pain.

It is certainly a good thing to have only *one* way to handle IR
remotes.  But the kernel side of that way *must* be in mainline.
Everything else simply isn't going to fly.

cheers,
  Gerd



  parent reply	other threads:[~2008-12-02 22:01 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
2008-11-23 22:58           ` Jon Smirl
2008-12-02 22:00       ` Gerd Hoffmann [this message]
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=4935B00D.5010302@redhat.com \
    --to=kraxel@redhat.com \
    --cc=jonsmirl@gmail.com \
    --cc=jrm8005@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirc@bartelmus.de \
    --cc=pavel@suse.cz \
    /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