On Sun, Jun 11, 2017 at 05:17:40PM +0100, Sean Young wrote: >On Sat, Apr 29, 2017 at 10:44:58AM +0200, David Härdeman wrote: >> >This can be implemented without breaking userspace. >> >> How? > >The current keymaps we have do not specify the protocol variant, only >the protocol (rc6 vs rc6-mce). So to support this, we have to be able >to specify multiple protocols at the same time. So I think the protocol >should be a bitmask. > >Also, in your example you re-used RC_TYPE_OTHER to match any protocol; >I don't think that is a good solution since there are already keymaps >which use other. > >So if we have an "struct rc_scancode" which looks like: > >struct rc_scancode { > u64 protocol; > u64 scancode; >}; > >Then if the keymap protocol is rc6, ir-keytable should set the protocol >to RC_BIT_RC6_0 | RC_BIT_RC6_6A_20 | RC_BIT_RC6_6A_24 | RC_BIT_RC6_6A_32 > | RC_BIT_RC6_MCE. > >If the old ioctl is used, then the protocol should be set to RC_BIT_ALL. > >I can't think of anything what would break with this scheme. I've tried coding up that solution before and the problem is that it'll still require heuristics in the presence of a mix of old and new style ioctl():s. For example: old_ioctl_set(0x1234 = KEY_A); new_ioctl_set(PROTOCOL_NEC, 0x1234 = KEY_B); new_ioctl_set(PROTOCOL_JVC, 0x1234 = KEY_C); old_ioctl_get(0x1234) = ? old_ioctl_set(0x1234 = KEY_D); new_ioctl_get(PROTOCOL_NEC, 0x1234) = ? -- David Härdeman