Messages in this thread | | | Date | Tue, 01 Dec 2009 15:02:18 +0100 | From | Gerd Hoffmann <> | Subject | Re: [RFC] What are the goals for the architecture of an in-kernel IR system? |
| |
On 12/01/09 12:49, Andy Walls wrote: > On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote: >> Once lirc_dev is merged you can easily fix this: You'll have *one* >> driver which supports *both* evdev and lirc interfaces. If lircd opens >> the lirc interface raw data will be sent there, keystrokes come in via >> uinput. Otherwise keystrokes are send directly via evdev. Problem solved. > > This will be kind of strange for lirc_zilog (aka lirc_pvr150). It > supports IR transmit on the PVR-150, HVR-1600, and HD-PVR. I don't know > if transmit is raw pulse timings, but I'm sure the unit provides codes > on receive. Occasionally blocks of "boot data" need to be programmed > into the transmitter side. I suspect lirc_zilog will likely need > rework....
Well, for IR *output* it doesn't make sense to disable evdev. One more reason which indicates it probaably is better to introduce a ioctl to disable evdev reporting. lircd will probably turn it off, especially when sending data to uevent. debug tools might not, likewise apps sending IR.
>> so killing the in-kernel IR limits to make ir-kbd-i2c > ^^^^^^^^^^^^^^^^^^^ >> being on par with lirc_i2c might be more useful in this case. > > I didn't quite understand that. Can you provide a little more info?
Such as throwing away the address part of rc5 codes ...
cheers, Gerd
| |