Re: Status of lirc. should I create new reciever driver against it?

[Maxim L. <max...@gm...>]

On Sat, 2009-05-30 at 12:50 -0400, Jon Smirl wrote:
> On Sat, May 30, 2009 at 12:16 PM, Maxim Levitsky
> <max...@gm...> wrote:
> > On Sat, 2009-05-30 at 11:56 -0400, Jon Smirl wrote:
> >> On Sat, May 30, 2009 at 10:42 AM, Maxim Levitsky
> >> <max...@gm...> wrote:
> >> > On Sat, 2009-05-30 at 10:23 -0400, Jon Smirl wrote:
> >> >> On Fri, May 29, 2009 at 5:50 PM, Christoph Bartelmus <li...@ba...> wrote:
> >> >> > Hi!
> >> >> >
> >> >> > Maxim Levitsky "max...@gm..." wrote:
> >> >> > [...]
> >> >> >> I want to write a kernel driver for this device, but I don't know if I
> >> >> >> need to write it against lirc, or recently posted on LKML in-kernel IR
> >> >> >> framework.
> >> >> > [...]
> >> >> >> What are your suggestions?
> >> >> >
> >> >> > Just implement a LIRC driver.
> >> >> >
> >> >> > The last suggestion that seemed to be accepted was that the IR data is
> >> >> > received by the LIRC drivers and is passed to a in-kernel decoder if the
> >> >> > user configures it so. Otherwise it's passed to lircd in user-space.
> >> >> >
> >> >> > The in-kernel decoder code was far from complete and I still have concerns
> >> >> > that it can work in all situations.
> >> >>
> >> >> Let's work on the design of this. My embedded systems they are using
> >> >> remotes that transmit the common protocols, the in-kernel state
> >> >> machine handles them fine. I also agree that there are weird device
> >> >> and protocols that the in-kernel statement won't handle. I also agree
> >> >> that there are user space implementations like the IR receiver via a
> >> >> sound card.
> >> >>
> >> >> There are a whole lot of things that haven't been designed. For
> >> >> example what does a minimal in-kernel IR device driver look like? What
> >> >> is it's sysfs interface? I attempted to make these drivers as small as
> >> >> possible.  There is a sysfs attribute that holds the raw input from
> >> >> the device, etc. I just did a first version of this model, it needs
> >> >> more design effort. For example it would be simple to add an attribute
> >> >> that stops the device pulses from being forwarded to the state machine
> >> >> and require use of the user space decoder.
> >> >>
> >> >> My goal would be to handle the 90% of common hardware/remotes with the
> >> >> in-kernel solution and then pass the rest off to user space. The
> >> >> in-kernel solution is only about 30KB of code.
> >> >
> >> > The problem is that for these 10% of remotes, one will have to create a
> >> > separate decoder, which is ok, but it will also have to create a keycode
> >> > <-> input keycode mapper similar to your configfs implementation.
> >> > And this is bad.
> >>
> >> You have that problem with any solution that is picked. It doesn't
> >> matter if the decoder for the weird 10% is in the kernel or lirc, it
> >> still has to be written.  AFAIK configfs is the only simple way to
> >> implement the mapping in-kernel. I wanted to reuse what was already
> >> available. Start off with state machines in user space and move them
> >> to the kernel when they are stable.
> >>
> >> A normal user will never deal with configfs. They'll run a little app
> >> that gets the state machine output from the kernel and then generates
> >> a script that builds the configfs entries to map it to a keystroke.
> >> That script will get added to init.d so that it gets restored on each
> >> boot. Longer term I'd like to see a set of default mappings developed,
> >> ie, always mapping the 1 button to KEY_1.
> >>
> >> I came up with the state machine approach trying to make Sony remotes
> >> works. Sony remotes transmit multiple protocols. LIRC only supports a
> >> single protocol in a config file so Sony remotes need to be used in
> >> raw mode with LIRC.  With in-kernel there are state machines for the
> >> three Sony protocols, you can build a single config file that covers
> >> the three protocols.
> >>
> >> > Also, one might like to do wierd things with standard protocol remotes.
> >> > You already had a request to create a 'shift' key.
> >> > Again, why not to process data in user space?
> >> > You don't have to use lircd, you could write your own daemon with same
> >> > state machines.
> >>
> >> The idea is to have 30KB of very reliable in-kernel code that can
> >> handle the common cases.  Kicking everything to user space gets into
> >> problems with process priorities on heavily loaded embedded CPUs.
> >>
> >> You are coming from a world that has four 3GHz CPU cores and 8GB of
> >> RAM.  Things are a lot different when you have a single 150Mhz CPU and
> >> 32MB RAM. lircd is 400KB plus all of the libraries it pulls in (the
> >> entire kernel is 1200KB). The 90% in-kernel solution is 30KB and no
> >> libraries.  But that's life in user space, all user space apps are 10x
> >> the size of a in-kernel equivalent.
> >
> > This isn't true. my userspace app, which combines driver and decoder for
> > NEC like protocols is 11 KB in binary form.
> 
> Obviously all of this can be done in user space. Microkernels move
> everything to user space.
> Linux is monolithic and device drivers go into the kernel.
Lets not turn this into a flamewar, its not about kernel vs userspace,
its about the fact that it is harder to modify the kernel, especially
for all kind of user needs, thus kernel tends to do what it is best
suited for, thats it talk to  hardware and process the data, and hand it
over to userspace.

I for example won't be against a kernel printer driver, or a kernel
video driver, or something like that, as long as kernel doesn't have to
obey complex settings.

And I consider parsing IR data, and mapping it to keys qute complex
task.


> 
> > (It only prints decoded byte sequences though)..
> 
> It's all of the other code that makes it bigger.
> 
> > The thing is that you don't have to use lirc!
> > Write your own small app, and I bet it can be fit into 10 KB
> > What I really don't like it to have data parsing in kernel.
> > (parsing according to a userspace policy that is).
> 
> Turn off the check box in Kconfig for building in the in-kernel state
> machines. Use sysfs to extract the raw data. Deal with the process
> priority problems when other things prevent your process from running.
> I want this stuff in kernel so that it behaves more deterministically.
If you want this for embedded systems, it might make a sense, for normal
usage I would prefer a userspace app.


> 
> The in-kernel mapping to key strokes is not required. Turn it off in
> Kconfig.  The decoded IR data is available on the input devices.
> Modify the apps to read this data instead of expecting key strokes.
> Of course you'll have to teach the apps about all of the different
> remotes. BTW It's not a parser, it is a one to one mapping function.
> We map device address to human names all over the kernel.
> 
> If you hate configfs, I could build little modules for each remote
> that does the mapping. But then you'd need to use the C compiler to
> change things.
> 
> The state machines are defined by the IR hardware they are not configurable.
> 
> 
> > Just another example, say user has 3 remotes, and uses them to control
> > devices, and with lirc:
> > Say I mark a unused key on each of the remotes, and unless I press it,
> > pc ignores that remote, thus it pays attention only to one remote that
> > did send that magic key.
> > Again this is easy to do in userspace. not so in kernel.
> 
> I did not want to add any scripting capability to the in-kernel
> interface. It just sends the events out the /dev/input devices. They
> come out in two forms - as IR events, or as mapped key stroke events.
> If you really want to do this, write an app that reads /dev/input,
> scripts the events, and then sends the data back in via uevent.
This was just an example, of  course there is no need for such things,
but yet userspace gives more flexibility.


> You can't do something like this with a mouse or keyboard either. They
> would also need to be scripted.
I agree with that.

> 
> > ( I agree that one might want to do same with ordinary keyboards, but
> > remotes are much more limited, thus wierd stuff like the above might
> > be reasonable)
> 
> Look in the input h file. There are predefined codes for over 500
> keys. All of the common ones are there and more can be added.
> 
> Think of it this way: why is IR special? Isn't it just another input
> method like mouse, keyboard, joystick, touchpad, etc. If it is not
> special, why can't the drivers be implemented in-kernel like all of
> the other Linux input drivers? If you flip this around, why shouldn't
> all of the mouse, keyboard, joystick, touchpad, etc drivers be removed
> from the kernel and reimplemented in user space?
These drivers are very different.
They know the hardware very well, they don't have to use user supplied
config for their job. They fit perfectly the kernel.


Best regards,
	Maxim Levitsky