Re: Fwd: [linux-usb-devel] USB IR receivers and evdev

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

On 14 Feb 2007 07:16:00 +0100, Christoph Bartelmus <li...@ba...> wrote:
> Hi Jon,
>
> on 13 Feb 07 at 23:46, you wrote:
> [...]
> > evdev doesn't just handle keyboards.
>
> Yes, sorry for simplifying it too much. I just opt for using uinput from
> user-space so that configuration is consistent for all devices.
> If some devices use the kernel input layer directly, you will have to
> configure the mapping from codes to events in kernel space. Otherwise
> you always do the mapping in lircd.conf in user space.
>

Adding uinput support would also let you get rid of all the X specific
code since X knows how to read evdev.You just need to do is add a
small section to your xorg.conf.

Are your interested in adding this support? Something like uinput is
not going to get used overnight but if the docs emphasize using evdev
first and then only using the client library if you want to do
something complicated, over time we can reduce the complexity of apps
using LIRC for simple things. This will work towards the goal of
unified input event handling.


> [...]
> > keyboard since they occur on a different event node. IR remotes would
> > get an event node for each remote seen.
> >
> > An example: pulseaudio needs two input modules:
> > Volume Control
> > # module-mmkbd-evdev
> > # module-lirc
> >
> > If lirc were to report events over evdev pulseaudio would only need
> > the evdev module.
> >
> > Using evdev to do event reporting can be done with either a user or
> > kernel space LIRC implementation. The uinput driver allows user space
> > programs to generate evdev events. evdev would allow LIRC to get rid
> > of the client library.
>
> Personally I don't want to get rid of the client library because it
> gives me much more configuration options.
> But I have no problem giving users the possibility to choose whether
> they want to use evdev or the lirc client library.
>
> [...]
> > How about getting your existing kernel drivers merged into mainline?
>
> I would like to see the kernel drivers being merged into mainline.
> But don't wait for me doing it. It simply won't happen.

If we fix the code up for submission will you test it and maintain the
drivers in the future?
I looked at the driver code and it isn't too bad, but all of the
multiple kernel version support will need to be removed. I only have a
couple of the devices so I can't really test the changes.


>
> [...]
> >> Additionally the Windows Media Center can be used as IR blaster. The
> >> input layer cannot be used to make use of this feature.
>
> > Vojtech, is this some way to send events the other direction through evdev?
>
> Sending an IR signal involves things like setting the carrier frequency,
> duty cycle, and then writing a stream of timing values.
> I think that evdev in general is not the right interface for this.

This could be worked into the evdev support. lircd.conf would contain
entries for the controls you wanted to send codes for. This info could
be used to created an uinput/evdev entry for the control. If evdev
supports pushing events, lircd could take the event and convert it to
IR info and push it down into the lirc drivers.

We need Vojtech to tell us if we can push events into uinput.

>
> Christoph
>


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