Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> writes: > Event input has the advantage that the keystrokes will provide an unique > representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized key<>function mapping. > Considering the common case > where the lirc driver will be associated with a media input device, the > IR type can be detected automatically on kernel. However, advanced users may > opt to use other IR types than what's provided with the device they > bought. I think most users would want to do that, though I don't have hard numbers of course. Why use a number of RCs simultaneously while one will do? > It should also be noticed that not all the already-existing IR drivers > on kernel can provide a lirc interface, since several devices have > their own IR decoding chips inside the hardware. Right. I think they shouldn't use lirc interface, so it doesn't matter. > 2) create a lirc kernel API, and have a layer there to decode IR > protocols and output them via the already existing input layer. In > this case, all we need to do, in terms of API, is to add a way to set > the IR protocol that will be decoded, and to enumberate the > capabilities. The lirc API, will be an in-kernel API to communicate > with the devices that don't have IR protocols decoding capabilities > inside the hardware. I think this makes a lot of sense. But: we don't need a database of RC codes in the kernel (that's a lot of data, the user has to select the RC in use anyway so he/she can simply provide mapping e.g. RC5<>keycode). We do need RCx etc. protocols implementation in the kernel for the input layer. "lirc" interface: should we be sending time+on/off data to userspace, or the RC5 etc. should be implemented in the kernel? There is (?) only a handful of RC protocols, implementing them in the kernel and passing only information such as proto+group+code+press/release etc. should be more efficient. Perhaps the raw RCx data could be sent over the input layer as well? Something like the raw keyboard codes maybe? We need to handle more than one RC at a time, of course. > So, the basic question that should be decided is: should we create a new > userspace API for raw IR pulse/space I think so, doing the RCx proto handling in the kernel (but without RCx raw code <> key mapping in this case due to multiple controllers etc.). Though it could probably use the input layer as well(?). > or it would be better to standardize it > to always use the existing input layer? I'd optionally provide a keyboard-alike input layer interface, with mappings (proto + raw code <> key) provided by userspace program. This should also work with multiple remotes. Then the existing drivers (such as saa713x with GPIO+IRQ-driven IR receiver (IR signal on/off generating IRQ)) should be converted. I think we shouldn't at this time worry about IR transmitters. -- Krzysztof Halasa -- 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
