Hi,

quoted text
>> 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.

quoted text
> 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


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/