Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux