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. The trouble with that is that every app that wants to use LIRC needs code to do it. Or you write macros that get triggered on a remote button press that inject key strokes into the application. With an evdev model the remote looks like another keyboard to the system. Hitting a number on the remote will generate the same events as hitting a number on your keyboard (except that they appear on two different evdev devices). The question is, how unified do you want the input model? For simple remote controls you might pick the first one. But then you realize that there are IR keyboards and mice that communicate the same way. LIRC has code to convert these devices into X input. The two in-tree ATI remote drivers have gone the evdev route. All other remotes are handled by LIRC. > > -- > 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
