Re: USB IR receivers and evdev

On Tue, Feb 13, 2007 at 03:32:38PM -0500, Jon Smirl wrote:
> On 2/13/07, Ville Syrjälä <[email protected]> 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.

-- 
Ville Syrjälä
[email protected]
http://www.sci.fi/~syrjala/

-------------------------------------------------------------------------
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