Hello, Benjamin Tissoires, on Fri 27 Jan 2017 18:13:14 +0100, wrote: > Well, it's quite an old issue, but it looks like no one cared much before :) I did, actually. > So by default, on Fedora and RHEL at least*, the Caps Lock LED is broken while > in a VT. Yes, and in Debian too, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514464 That was the trigger for my kbd LED work. > I tracked down the issue to be a change in ckbcomp introduced because > the kernel just can't properly handle all keymaps. However, if the keymap now > works thanks to the work around in place, the LED just doesn't. Yes, and ckbcomp now just has to properly set the LED trigger for capslock. Something like: echo kbd-ctrlllock > /sys/class/leds/input0::capslock/trigger see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514464#114 > This series aims at trying to have a consistent LEDs status while in VT. > It detects the ckbcomp workaround (which seems mainline now), Urgl. > and syncs both caps lock with left control lock when it has to. Urgl. > This way, we shouldn't > break existing user-space if the distribution changes the trigger to > kbd-controllllock instead of kbd-capslock. Urgl. It's ckbcomp's fault for using another trigger. It's up to ckbcomp to make sure that keyboard use the right trigger for the capslock led. The kernel shouldn't try to circumvent that. Samuel -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
