[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.022 / U:6.556 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site