On 14 Feb 2007 07:16:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
