Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> writes: >> (This is no recommendation for lirc. I have no idea whether a >> pulse/space -> scancode -> keycode translation would be practical >> there.) It would, but not exactly in the present shape. > For example, there are several bttv and saa7134 devices that polls (or receive > IRQ interrupts) to detect pulses (and the absense of them) in order to create > a pulse/space code. The conversion from pulse/space to scancode is done inside > the driver, with the help of some generic routines and based on the protocol > specifications. Right. There are currently several problems (I'm quite familiar with saa713x RC5 code): the one that it barely works and is not implemented for most such "GPIO/IRQ-driven" cards (as of 2.6.29 or so). This could be fixed, I even have a working though quick&dirty patch. Another: the RC5 allows for groups and codes within groups. The mapping can only use one group, and there can only be one mapping. These design limitations mean it's unusable in many cases. > Those devices where the decoding is done by software can support any > IR protocols. Yes, and there can be multiple remote controllers, and multiple code groups within a remote. > This can be solved by adding a few ioctls to enumerate the supported > protocols and to select the one(s) that will be handled by the kernel > driver. The driver may have to handle many protocols simultaneously. This is not a problem from a technical POV. -- 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
