On 2/13/07, Ville Syrjälä <[EMAIL PROTECTED]> wrote: > On Tue, Feb 13, 2007 at 10:37:10AM -0500, Jon Smirl wrote: > > On 2/13/07, Ville Syrjälä <[EMAIL PROTECTED]> wrote: > > > On Mon, Feb 12, 2007 at 10:10:07PM -0500, Jon Smirl wrote: > > > > On 2/12/07, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > On Sun, Feb 11, 2007 at 03:20:20PM -0500, Jon Smirl wrote: > > > > > > Most drivers for USB IR remote controls are out of tree. They are > > > > > > located here: > > > > > > http://www.lirc.org/ > > > > > > > > > > > > Why aren't these in-tree? > > > > > > > > > > Because the lirc developers do not have the time to submit them > > > > > upstream > > > > > :( > > > > > > > > > > Feel free to clean them up and work with the developers to get them > > > > > upstream, I tried over a year ago and gave up... > > > > > > > > How should IR receivers be handled in the kernel? For example the > > > > ati_remote2 support already in the kernel has a mapping table like > > > > this for keys that get passed up through evdev. > > > > > > > > static struct { > > > > int hw_code; > > > > int key_code; > > > > } ati_remote2_key_table[] = { > > > > { 0x00, KEY_0 }, > > > > { 0x01, KEY_1 }, > > > > { 0x02, KEY_2 }, > > > > { 0x03, KEY_3 }, > > > > { 0x04, KEY_4 }, > > > > { 0x05, KEY_5 }, > > > > { 0x06, KEY_6 }, > > > > > > > > This model breaks down when you point remotes from different > > > > manufacturers at the receiver. > > > > > > > > You want a model more along the lines of: > > > > 1) receiving a xmit with a new manufacturer id cases an evdev device > > > > to be dynamically created > > > > 2) wait for user space to load a mapping table into new device (udev > > > > event?) > > > > 3) now start passing mapped events on up to user space. > > > > > > > > LIRC passes up the full event to user space and then uses tables to > > > > decode it there. But that model eliminates using evdev. > > > > > > AFAIK uinput should allow you to write userspace evdev drivers. > > > > That is what LIRC is doing currently. > > I thought it has a lircd daemon that apps talk to. > > > The trouble with that is that > > every app that wants to use LIRC needs code to do it. > > AFAIK with uinput the apps doesn't need any special code. The only > difference to in-kernel evdev drivers is that the actual device driver > lives in a user space daemon. So if lircd would use uinput apps should > just open("/dev/input/event<something>") and use read(), write(), > ioctl() to talk to the driver, same as other evdev devices. Someone > correct me if I'm totally wrong here.
I poked around in what meager uinput doc I could find. It is not clear if events fed into uinput appear on their own evdev device or if they get merged into another stream. For sure there are two different styles of doing this: 1) ir driver sends raw ir codes to user space, user space maps, sends back via uinput 2) load mapping table into driver and have driver directly generate evdev events There are 1000s of mapping tables but they are less than 1K each. You need one table for each remote. lirc daemon is about 80K. Which is the better model? Most IR units function as a blaster too, so the events have to go back the other way too. Current LIRC code doesn't use uinput, it has a socket interface. > > The two in-tree ATI remote drivers have gone the evdev route. All > > other remotes are handled by LIRC. > > BTW the ATI remotes are RF w/ their own USB receivers, not IR. RF protocol is probably proprietary so there is no way to point another transmitter at the receiver so it doesn't have the multi-remote mapping problem that IR has. > > -- > Ville Syrjälä > [EMAIL PROTECTED] > http://www.sci.fi/~syrjala/ > -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
