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

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

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?

>
>
> Best regards,
>        Maxim Levitsky
>
>



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