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]

 



  Hi,

A current related problem is that i2c based devices can only be bound to
only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time.
Currently it is somewhat up to the bridge driver which binding is
preferred.  Discussion about this for the pvrusb2 module had the biggest
email churn IIRC.

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.

cheers,
  Gerd

PS:  Not sure this actually makes sense for the i2c case, as far I know
     these do decoding in hardware and don't provide access to the raw
     samples, 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux