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
