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

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

On Sat, 2009-05-30 at 15:43 -0400, Jon Smirl wrote:
> On Sat, May 30, 2009 at 3:26 PM, Maxim Levitsky <max...@gm...> wrote:
> > On Sat, 2009-05-30 at 15:04 -0400, Jon Smirl wrote:
> >> On Sat, May 30, 2009 at 2:26 PM, Maxim Levitsky <max...@gm...> wrote:
> >> > On Sat, 2009-05-30 at 14:10 -0400, Jon Smirl wrote:
> >> >> On Sat, May 30, 2009 at 2:01 PM, Maxim Levitsky <max...@gm...> wrote:
> >> >>
> >> >>
> >> >> >> 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.
> >> >>
> >> >> Checkout keyboard translation tables:
> >> >> man loadkeys
> >> > Well, this is for console, and ugly.
> >> >
> >> > I had a lot of fight with kernel keymaps btw.
> >> > I have even wrote my own keymap.
> >> > I don't use linux console anymore.
> >>
> >> The point of having keymaps in the kernel is so that all apps can
> >> share them. X "the Operating System" is doing a bunch of stuff that
> >> really belongs to the kernel. That is slowly being changed - X doesn't
> >> scan the PCI bus any more. Input is being worked on. Mode setting is
> >> migrating to the kernel.
> >>
> >> Those keymaps inside of X can't be used by command line apps because X
> >> may not be running. That path has led to duplicate keymapping systems.
> >>
> >> Sure we could make a universal keymapping daemon. But that's the
> >> microkernel vs monolithic kernel argument.
> >>
> >> You can push the entire kernel in to user space - UML has already done
> >> it. But do you really want to do that?
> > Lets stop here.
> > I am not against kernel code. period.
> > The opposite is true!
> >
> >
> > Everybody has the right to have its own opinion, I currently think that
> > IR decoding should be done in userspace, _due_ to pure userspace
> > drivers.
> 
> Then forget about merging LIRC into the kernel because that's not
> going to happen until LIRC is integrated into the evdev input event
> model.



Why not integrated?

_kernel_ sends ir data.
lirc decodes it and passes it back via uinput


This is the quote from Christoph Bartelmus's mail:

"
> 2 - make lirc use uinput, and _depricate_ its own interface.
> (and in same time clean it up)

lircd already does have uinput support...

"


What wrong with that?


Best regards,
	Maxim Levitsky