[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170127171318.2596-1-benjamin.tissoires@redhat.com>
Date: Fri, 27 Jan 2017 18:13:14 +0100
From: Benjamin Tissoires <benjamin.tissoires@...hat.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>,
Samuel Thibault <samuel.thibault@...-lyon.org>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] TTY: fix Caps Lock LED
Hi,
Well, it's quite an old issue, but it looks like no one cared much before :)
So by default, on Fedora and RHEL at least*, the Caps Lock LED is broken while
in a VT. 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.
This series aims at trying to have a consistent LEDs status while in VT.
It detects the ckbcomp workaround (which seems mainline now), and syncs
both caps lock with left control lock when it has to. This way, we shouldn't
break existing user-space if the distribution changes the trigger to
kbd-controllllock instead of kbd-capslock.
Cheers,
Benjamin
* ubuntu also seems affected:
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/425704
Benjamin Tissoires (4):
tty/vt/keyboard: use defined macros for masks
tty/vt/keyboard: Fix Caps Lock LED on major distributions
tty/vt/keyboard: reset the LEDs state at each console change
Input: leds - force the LED status after .probe()
drivers/input/input-leds.c | 33 ++++++++++++++++++++++++++++
drivers/tty/vt/keyboard.c | 55 +++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 83 insertions(+), 5 deletions(-)
--
2.9.3
Powered by blists - more mailing lists