On Fri, Apr 28, 2017 at 12:58:32PM +0100, Sean Young wrote: >On Thu, Apr 27, 2017 at 10:34:18PM +0200, David Härdeman wrote: >> Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core >> and the nec decoder without any loss of functionality. At the same time >> it ensures that scancodes for NEC16/NEC24/NEC32 do not overlap and >> removes lots of duplication (as you can see from the patch, the same NEC >> disambiguation logic is contained in several different drivers). >> >> Using NEC32 also removes ambiguity. For example, consider these two NEC >> messages: >> NEC16 message to address 0x05, command 0x03 >> NEC24 message to address 0x0005, command 0x03 >> >> They'll both have scancode 0x00000503, and there's no way to tell which >> message was received. > >It's not ambiguous, the protocol is different (RC_TYPE_NEC vs RC_TYPE_NECX).
It's ambigous in any context where the protocol is not known (e.g. when old-style ioctl():s are performed) or in contexts where protocols are bundled (i.e. when the only information about protocols come from the sysfs file). Anyway, I'm very open to leaving NEC well alone if that means we can make some progress on the more important issue of protocol-enabled keytables. :) >> In order to maintain backwards compatibility, some heuristics are added >> in rc-main.c to convert scancodes to NEC32 as necessary when userspace >> adds entries to the keytable using the regular input ioctls. These >> heuristics are essentially the same as the ones that are currently in >> drivers/media/rc/img-ir/img-ir-nec.c (which are rendered unecessary >> with this patch). > >There are issues with the patch which breaks userspace, as discussed >in the previous patch. None of those issues have been addressed. It is impossible to add protocol information without affecting userspace, what we should be focusing on is the best way to ameliorate the effects. As a simple example, consider new-style ioctls doing: EVIOCSKEYCODE_V2 (SONY, 0x001f) = KEY_NUMERIC_2 EVIOCSKEYCODE_V2 (SANYO, 0x001f) = KEY_NUMERIC_1 After that, what should these two ioctl():s perform/return?: EVIOCGKEYCODE (0x001f) -> ? EVIOCSKEYCODE (0x001f) = KEY_* -- David Härdeman
