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