From: <li...@ba...> - 2007-02-14 06:18:51
|
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. [...] > 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. [...] >> 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. Christoph |