Menu
▾
▴
Fwd: [linux-usb-devel] USB IR receivers and evdev
|
From: Jon S. <jon...@gm...> - 2007-02-13 23:04:14
|
LIRC folks, there is an on-going discussion about possible future designs for IR support in the kernel. What's your take on how to do this? Forwarded Conversation Subject: USB IR receivers and evdev ------------------------ From: Jon Smirl <jon...@gm...> To: Greg KH <gr...@kr...> Cc: lin...@li..., Vojtech Pavlik <vo...@su...> Date: Mon, Feb 12, 2007 at 10:10 PM On 2/12/07, Greg KH <gr...@kr...> 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 locat= ed 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[] =3D { { 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. -- Jon Smirl jon...@gm... -------- From: Greg KH <gr...@kr...> To: Jon Smirl <jon...@gm...> Cc: lin...@li..., Vojtech Pavlik <vo...@su...> Date: Tue, Feb 13, 2007 at 1:26 AM [Quoted text hidden]I don't know what model to use, ask the input subsystem developers :) thanks, greg k-h -------- From: Ville Syrj=E4l=E4 <sy...@sc...> Reply-To: Jon Smirl <jon...@gm...>, Greg KH <gr...@kr...>, Vojtech Pavlik <vo...@su...>, lin...@li... To: Jon Smirl <jon...@gm...> Cc: Greg KH <gr...@kr...>, Vojtech Pavlik <vo...@su...>, lin...@li... Date: Tue, Feb 13, 2007 at 3:17 AM On Mon, Feb 12, 2007 at 10:10:07PM -0500, Jon Smirl wrote: [Quoted text hidden]AFAIK uinput should allow you to write userspace evdev drivers. -- Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ -------- From: Jon Smirl <jon...@gm...> To: Jon Smirl <jon...@gm...>, Greg KH <gr...@kr...>, Vojtech Pavlik <vo...@su...>, lin...@li... Date: Tue, Feb 13, 2007 at 10:37 AM [Quoted text hidden]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=E4l=E4 > sy...@sc... > http://www.sci.fi/~syrjala/ > [Quoted text hidden] -------- From: Ville Syrj=E4l=E4 <sy...@sc...> Reply-To: Jon Smirl <jon...@gm...>, Greg KH <gr...@kr...>, Vojtech Pavlik <vo...@su...>, lin...@li... To: Jon Smirl <jon...@gm...> Cc: Greg KH <gr...@kr...>, Vojtech Pavlik <vo...@su...>, lin...@li... Date: Tue, Feb 13, 2007 at 2:22 PM [Quoted text hidden]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. ... > 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. -- [Quoted text hidden] -------- From: Jon Smirl <jon...@gm...> To: Greg KH <gr...@kr...>, Vojtech Pavlik <vo...@su...>, lin...@li... Date: Tue, Feb 13, 2007 at 3:32 PM [Quoted text hidden]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 e= vents 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=E4l=E4 > sy...@sc... > http://www.sci.fi/~syrjala/ > [Quoted text hidden] -------- From: Ville Syrj=E4l=E4 <sy...@sc...> Reply-To: Jon Smirl <jon...@gm...>, Greg KH <gr...@kr...>, Vojtech Pavlik <vo...@su...>, lin...@li... To: Jon Smirl <jon...@gm...> Cc: Greg KH <gr...@kr...>, Vojtech Pavlik <vo...@su...>, lin...@li... Date: Tue, Feb 13, 2007 at 4:44 PM On Tue, Feb 13, 2007 at 03:32:38PM -0500, Jon Smirl wrote: > On 2/13/07, Ville Syrj=E4l=E4 <sy...@sc...> wrote: > > > > 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. A quick look at the code suggests that using write() + UI_DEV_CREATE ioctl you can register an input device (which should appear as /dev/input/eventX via udev). However it looks like you need a daemon process per device since there is no 'add new device' ioctl and it uses struct file to identify the device. > 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 Maybe this could use the firmware loader. > 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. So there would be a huge number of "firmwares". > Which is the better model? I don't know. Can option 2 cover all current cases or does lirc do something more than table lookups? > Most IR units function as a blaster too, so the events have to go back > the other way too. BTW the ati_remote2 receiver has two jacks, which are for connecting IR blasters (according to rumor). However I don't think such blasters were ever sold :( > Current LIRC code doesn't use uinput, it has a socket interface. Requiring additional support code in apps/libs :( > > > 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. Exactly, so the lirc drivers for these should not be merged. -- [Quoted text hidden] -------- |
