Re: drop lircd!

[Leonid F. <lf...@il...>]

There's only one critical difference between current implementation and 
proposed /dev/input:
current design uses /dev/lirc and proposed uses /dev/input/event<x>. 
Others are just derivatives
because :
1. You still using lircd for serial, usb or others signal decoding 
(where "drop lircd" comes from ???)
2. You still need to compile and load kernel module
3. You still need client library for most applications

Putting events from remote to keyboard queue will not work. Except for 
stand-alone boxes that
are controlled by remote control only, there's no point for doing such 
strange thing. The point is
to have programs controlled by remote and by console to run independently.


Gerd Knorr wrote:

>>>Hi,
>>>
>>>This is a prof-of-concept port of a lirc infrared remote driver to the
>>>2.6 kernel input layer.  I picked lirc_i2c.c, simply because I have
>>>hardware to play with for that one.  For now it works with Hauppauge
>>>WinTV cards only.
>>>      
>>>
>
>  
>
>>Not all recievers have kernel module.
>>    
>>
>
>Those which have are very painful to maintain.  Especially those drivers
>where a part of the driver is in the standard kernel and another part
>(the lirc one) isn't.  All bttv based stuff for example.  A bridge
>module (lirc_gpio for example) is needed, and the only reason is that
>lirc_dev isn't part of the kernel.  I'd love to have a bttv-ir.c
>instead and have bttv register the remote directly.
>
>saa7134 + cx88 are the next candidates, and I simply don't want to
>create the same mess bttv + lirc do right now again.  Ok, what are the
>options?
>
>  (1) put lirc into the standard kernel.  Any chance this really
>      happens?  Doesn't look like this is going to happen anytime
>      soon to me.  There even isn't a official minor number for
>      /dev/lirc.
>  (2) Look for some other way.
>
>For (2) the input layer is the obvious candidate.  The dvb folks do this
>already (see drivers/media/dvb/ttpci/av7110_ir.c), and I want to follow
>that route too.
>
>  
>
>>There's too match of serial or usb or other devices that have their
>>decoding in user-space, i.e. in lircd.
>>    
>>
>
>IMHO this isn't a problem.  There are several options to use the input
>layer.
>
>The simplest way is to make lircd also accept input from
>/dev/input/event<n>, which would allow to drop /dev/lirc and use the
>input layer instead in the long run.  Input from serial/usb devices
>continues to work like it does today.  As lircd still does the event
>dispatching to multiple apps in that case it can just ask for exclusive
>access to that input device, which would prevent IR key strokes go to
>the linux keybaord driver and appear on the console and in X11.
>
>Another -- IMHO better and more flexible -- way would be to do all event
>routing with the input layer.  It may be useful to have another input
>event type for that, so the IR key presses can be disturgished from
>keyboard key presses.  lircd as it exists today would go away, multiple
>smaller daemons would do the work instead.  One daemon can handle the
>userspace decoding of the IR input and send the results to the input
>layer (via /dev/input/uinput).  Another one could handle lircd's
>networking features (i.e. read /dev/input/event<x> on one host and put
>that into /dev/input/uinput on the other).  liblirc_client.a can read
>from /dev/input/event<x> directly.
>
>  
>
>>>very simple: Compile the driver, load the module, press keys on the
>>>remote and see them arrive in your shell.
>>>      
>>>
>
>  
>
>>Why should keys from remote come to my shell ?? Lirc is the way to
>>control very specific application, not to enter text in console
>>    
>>
>
>For the shell it is not very useful.  Which does not mean that there is
>absolutely no point in doing that.  There are applications which can be
>controled just fine with the IR remote sending normal keystrokes,
>teletext browsers for example.  Why not have that option?
>
>  Gerd
>
>
>
>  
>

-- 
---------------------------------------------------------

"Rise and conquer, let the infidels burn"


This message may contain confidential, proprietary or legally privileged 
information. The information is intended only for
the use of the individual or entity named above. If the reader of this 
message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by telephone, or by 
e-mail and delete the message from your computer.