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

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

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.


>
>
> Best regards,
>        Maxim Levitsky
>
>



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