On Fri, Apr 28, 2017 at 08:42:13PM +0100, Sean Young wrote: >On Fri, Apr 28, 2017 at 06:59:11PM +0200, David Härdeman wrote: >> On Fri, Apr 28, 2017 at 08:31:33AM -0300, Mauro Carvalho Chehab wrote: >> >Em Thu, 27 Apr 2017 22:34:23 +0200 >> >David Härdeman <da...@hardeman.nu> escreveu: >> ... >> >> This patch changes how the "input_keymap_entry" struct is interpreted >> >> by rc-core by casting it to "rc_keymap_entry": >> >> >> ... >> > >> >Nack. >> >> That's not a very constructive approach. If you have a better approach >> in mind I'm all ears. Because you're surely not suggesting that we stay >> with the current protocol-less approach forever? > >Well, what problem are we trying to solve actually?
I'm not sure what the confusion is? Last time around we discussed this there seemed to be general agreement that protocol information is useful? >Looking at the keymaps we have already, there are many scancodes which >overlap and only a few of them use a different protocol. So having this >feature will not suddenly make it possible to load all our keymaps, it >will just make it possible to simultaneously load a few more. That's not really the point, overlaps in scancode && protocol cannot be distinguished. But overlaps in scancode can be. I have remotes which overlap in scancode even though they have different protocols. >> >> That's a gross oversimplification. > >This can be implemented without breaking userspace. How? -- David Härdeman
