On Sun, 05 Apr 2009 08:44:15 -0400 Andy Walls <awalls@xxxxxxxxx> wrote: > The scope of a complete kernel IR infrastructure goes a bit beyond I2C > bus devices that are only input devices. > > What's the scope of what you want to tackle here? > > I certainly don't want to reinvent something that's going to look just > like the LIRC driver model: > > http://www.lirc.org/html/technical.html > > Which already has an infrastructure for IR driver module writers: > http://www.lirc.org/html/technical.html#lirc_dev As other out-of-tree drivers that have a long trip, I suspect that lirc did some assumptions, while event and v4l did different ones. Due to kernel rules to keep API's forever, we should take some care to avoid breaking the existing API in favor to another one. So, this probably means some lirc redesign, in order to get his way to kernel, on a similar path that ivtv driver did. The part of lirc that I'm concerned with are the ones that work with GPIO and I2C devices and the API. > Do we just convert lirc_dev, lirc_i2c, and lirc_zilog to a cleaned up > set of in kernel modules? We should cover also the lirc gpio module(s). > lirc_i2c can certainly be broken up into > several modules: 1 per supported device. I don't think that breaking it into one per device is the better approach. IMO, we need a common i2c glue (like what ir-kbd-i2c provides, if we remove the legacy stuff) that it is IR independent. the IR dependent parts can be part of ir-common module or eventually we can split it into sub-modules. > Should these create an input > device as well to maintain compatability with apps expecting an > ir-kbd-i2c like function? For sure. The event interface is the kernel way for input devices. There are also other IR devices (like IR mouses and keyboards) already handled via input/event interface. On a first glance, I don't see the need to exporting raw data to userspace, although I understand why lirc needs this currently. > Or do we split up ir-kbd-i2c into per device modules and in addition to > the input event interface, have it register with the lirc_dev module? > > Do we leverage LIRC's lirc_dev infrastructure module at all? (I think it > would be a waste of time not to do so.) IMO, the proper workflow would be to discuss lirc as a hole with Lirc people, linux-media and input/event people. Cheers, Mauro -- 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
