On Sat, 2019-06-22 at 19:56 +0200, Pavel Machek wrote: > On Fri 2019-06-21 13:39:39, Bastien Nocera wrote: > > On Sun, 2019-06-16 at 18:58 +0200, Pavel Machek wrote: > > > Hi! > > > > > > > I dug out a fair bunch of remote controls I got around 10 years > > > > ago[1], > > > > and started trying them all out. > > > > > > > > I bumped into a couple of problems: > > > > > > > > - the Snapstream Firefly remote ([2] using the rc-snapstream- > > > > firefly > > > > keymap and the ati_remote protocol) creates 2 input device > > > > nodes, > > > > one > > > > for the remote keys, one for the mouse mode. The mouse button > > > > on > > > > the > > > > remote just sends KEY_MODE, and doesn't change the mode, > > > > nothing is > > > > ever sent on the mouse device node > > > > > > > > - the Streamzap remote ([3]) uses KEY_NUMERIC_[0-9] keycodes, > > > > just > > > > like > > > > a small minority of other devices. Is there any reason for them > > > > not > > > > to > > > > use KEY_[0-9] instead? Or for all of them to use KEY_NUMERIC_*, > > > > for > > > > consistencies' sake. I can send patches for those. > > > > > > This may be a bit of fun; consistency is good but this will > > > change > > > behaviour for people, > > > right? > > > > > > So.. be careful :-). > > > > I'm not really sure how one can be "careful" doing that. > > You could do an config option and then pretend breakage is user > decision, for example. > > Or better just change it and see what happens. Patch sent :) > > You can check this patch to lirc from 2008 to see what it might end > > up > > looking like ;) > > https://people.redhat.com/bnocera/lirc-fix-remote-keycodes.patch > > > > It doesn't really answer my question about whether this discrepancy > > was > > intended though. > > Probably not intended. > > Pavel
