[lkml]   [2009]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 ...


 \ /
  Last update: 2009-12-01 15:05    [W:0.169 / U:4.516 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site