Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
fix lirc cross-compilation and non-working left/right keys #1281
don't merge yet, please review and test
Since diagonal key support was added in kernel 4.7 via commit torvalds/linux@4883269 using the default release suffix of _UP for transporting key-up events from lircd to lircd.-uinput is broken.
KEY_LEFT_UP and KEY_RIGHT_UP are now valid keycodes and lircd-uinput will interpret them differently (diagonal-key-down instead of left/right key up) leading to non-working left/right keys. See for example this irw output: https://forum.libreelec.tv/thread-4413-post-31915.html#pid31915
This problem went unnoticed so far because of another issue: during cross-compilation the lirc build picked up the linux include with valid keycodes from the build host instead of the target. So when compiling on a system with older userspace kernel headers installed lircd-uinput worked as before because it didn't know about KEY_LEFT/RIGHT_UP. But when compiling on a system with newer userspace kernel headers installed realase handling of left/right keys broke.
The first commit fixes lircd->lircd-uinput communication by using a different suffix.
The second commit tries to fix lirc cross-compilation:
During a normal (non-cross) build lib/input_map.inc and lib/lirc/input_map.inc in the source folder will be automatically regenerated matching the keycodes from /usr/ijnclude/linux/input-event-codes.h (or /usr/include/linux/input.h on older kernels). This part of the Makefile is nasty, though, when build is started from the object folder input_map.inc will end up there. The build seems to pick it up fine (instead of the one(s) in the source folder), but still it's not nice to have 2 different input_map.inc files sitting around.
I've fixed this by disabling automatic regeneration of input_map.inc during make and doing it manually in package.mk instead.
For removing the build-host-include issue there are 2 options: either patch the lirc-make-devinput script to point it to the target includes or add a parameter to the lirc-make-devinput, pointing it to the location of the kernel include (the input-event-codes.h). I choose the first approach, although it's a little nasty to patch files it'll still work if the script is called from the lirc build so it's more robust. Also it's a little bit easier, otherwise I we might have to re-implement the input-event-code.h->input.h fallback in package.mk.
The third commit disables generation of LIRC release events in eventlircd. Kodi doesn't seem to handle them (they just show up in the logs) and since _UP is now ambiguous we'd have to use another suffix for kodi anyways..
InuSasha left a comment •
Test with a former broken configuration.
Also the cherry-pick for the LE8 is working.
Thanks a lot for testing!
lirc-make-devinput is also installed by default in debian https://packages.debian.org/stretch/amd64/lirc/filelist . It doesn't make too much sense on a LE install (there are no kernel headers anyway) but also won't hurt much. Sure, it's not nice that it contains the host build path - if there are concerns we can just remove it completely from the install.
As for your patch: we'd need to do that slightly differently, input-event-codes.h was added in kernel 4.4 and there are several platforms /(wetek, amlogic) that use quite ancient 3.x kernels. So we'd have to add a check to package.mk and then add that as a parameter to lirc-make-devinput -i. Best place for that would be in pre_make_target, patching the generated Makefile in the objdir.
Not sure if that is more robust than patching lirc-make-devinput, both could change in the next lirc release :)
Ideally we'd have some configure parameter we could pass in (or let configure autodetect it), I'll contact the lirc guys about that.
@HiassofT you are right... i forgotten the proprietary cpus with historical linux kernels...
Now, i make a build test with wetek_play and press the review button.
Sorry for being late on that one ... although i agree that the default
I understand that kodi doesn't use this, but is there anything else that would require to remove it ?
@LongChair the _UP events just cluttered kodi.log so I saw very little point in keeping them. If you want them in your tree I think it'd be best to add a distribution/project specific eventlircd systemd file. Or maybe think about some way to make the eventlircd options configurable. But just overriding the LE systemd file would probably be the easiest solution.