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

[Jon S. <jon...@gm...>]

On Sat, May 30, 2009 at 3:53 PM, Maxim Levitsky <max...@gm...> wrote:
> 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?


The state decoders for the protocols is a grand total of 730 lines of
code. Pushing that into user space requires an interface to be spec'd
and a separate app to be distributed and documented. Now the interface
needs to be versioned and the app has to match versions.  It open up
problems with the user space daemon not running when it needs to. The
user space daemon can get killed by OOM. Now init has to be modified
to make sure it restarts, etc, etc....

Just put the 730 lines of code in the kernel and get rid of these
issues. All of the other input devices do it that way.


>
> _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
>
>



-- 
Jon Smirl
jon...@gm...