Hello,

While upgrading from console-data's keymaps to console-setup, my caps
lock became a shift lock, and the caps lock led doesn't work any more.

This is due to these few lines:

# A hack to work around a bug in the kernel/loadkeys
if (! $acm) {
    $xkbsym_table{'Caps_Lock'} = 'Shift_Lock';
    $xkbsym_table{'ISO_Lock'} = 'Shift_Lock';
}

which happen to be always executed as my system is UTF-8, just like all
future installed Debian systems.  Why is this hack needed?  We should
rather fix the bug where it belongs instead of introducing others on all
future installed systems... :)

If the reason has been lost in history (the code dates back from at
least 2005) then we should probably apply the patch to fix the common
case, and let the real bug reappear and get fixed the proper way.

Samuel

Samuel Thibault, le Thu 05 Feb 2009 10:34:09 +0100, a écrit :

Oh, that's probably due to

http://bugzilla.kernel.org/show_bug.cgi?id=7746

Bummer, that's not an easy one.

Samuel

The reason is known - Caps_Lock works only for English letters.  I think
there was some patch that fixed the problem but I don't know if it is
applied in the Debian kernel.  I'll have to remember and check this.

Anton Zinoviev

Anton Zinoviev, le Thu 05 Feb 2009 13:04:42 +0200, a écrit :

More precisely, as described in the bug report, it works only for the
underlying 8bit charset, so in unicode it's latin1.

Samuel

I found the patch that needs to be applied and it is relatively simple.

http://lists.altlinux.org/pipermail/kbd/2008-April/000123.html

Anton Zinoviev

Anton Zinoviev, le Thu 05 Feb 2009 13:28:07 +0200, a écrit :

Thanks, that's mine :)

I don't have the time to develop right now, but the idea would then be
to double the number of keymaps to 128, to have "capsed" versions of
each of the current keycode translations.  And about the led issue, we
need to ask the kernel for an interface to be able to configure which
lock should drive which led.

Samuel

Samuel Thibault, le Thu 05 Feb 2009 12:39:08 +0100, a écrit :

That was bug #452103, now closed, and indeed the patch is applied so you
can use it.

Samuel

A good idea. :)

Idealy some future version of loadkeys should automaticaly double the
keysyms and convert CapsLock to CapsShift and in order to do this no
keymap should use CapsShift directly.  In console-setup maybe it will be
better to use CtrlL_Lock instead of CapsShift_Lock as CtrlL_Lock is
supported by console-tools and by all kernels.

Anton Zinoviev

clone 514212 -1
retitle -1 caps lock led does not show up
thanks

Cloning the bug as the lock led not showing up is an independant matter
(which depends on kernel support actually).

Samuel

Samuel Thibault, le Sat 07 Feb 2009 23:04:17 +0100, a écrit :

leds-route-kbd-leds-through-the-generic-leds-layer.patch

Samuel

Hi, I've published a workaround based on a loadkeys configuration file. It is
downloadable, with explanations(in french) here: http://www.fdn.fr/~sascoet/

Hi, on an azerty french mapped keyboard, the above configuration disable the
ability to write É, È, Ç and À with Caps+(é, è, ç or à on digits keys in the
superior area of the keyboard). About the "Caps_On" key definition, I can guess
that it is supposed to work like a "Shift_Lock"... But, what I really don't
understand is the fact that the "Pause" key, becoming a "Caps_Lock"(so, I was
guessing, like the original behaviour of the original "caps lock" key) suffers
frome the same issue! Additionnaly, it lights up the led, at the contrary of
the default "caps lock" key(and which is the original covered in this ticket)

Helo,

Any news? Debian 7.7 is still affected.

This is all weird.

CtrlL_Lock doesn't turn on the led but works fine for all Polish
diacritics.

Caps_Lock turns on led on the led but only Ó is correctly
capitalised.

Hello,

Lukasz Stelmach, le Sat 03 Jan 2015 22:34:43 +0100, a écrit :

Yes, I know.  This is still being discussed upstream on linux-kernel,
see the "INPUT: Route keyboard LEDs through the generic LEDs layer"
thread.

(and please keep the subject of the bug report in replies, I don't know
anybody who knows bug # by heart :))

Samuel

Hello,

Samuel Thibault, le Thu 05 Feb 2009 12:39:08 +0100, a écrit :

Dmitry Torokhov, le Mon 08 Jun 2015 14:43:07 -0700, a écrit :

Anton, this is the interface proposed by the input maintainer, Dmitry,
to change which modifiers gets to light the keyboard LEDs (the exact
names may change, but the principle should be firm).  I know this is
inconvenient for console-setup for handling hotplugged keyboards, but
Dmitry prefers to avoid introducing a virtual multiplexer as explained
below:

Samuel

Ok, the inconvenience is not a problem.  The problem is I don't
understant the meaning of this. :)

Is there some documentation or a sample code I can read?

Anton Zinoviev

Hello,

Anton Zinoviev, le Tue 09 Jun 2015 19:03:39 +0300, a écrit :

Putting

SUBSYSTEM=="leds", ENV{DEVPATH}=="*/input*::capslock", ATTR{trigger}="kbd-ctrlllock"

in /etc/udev/rules.d/50-leds.rules seems to be doing the work. It'd be
good to include this in the documentation along the patch.

Samuel

Samuel Thibault, le Thu 11 Jun 2015 10:08:09 +0200, a écrit :

Except that it makes my system unbootable. For whatever reason, systemd
indefinitely waits for the network to become available...

Samuel

Samuel Thibault, le Thu 11 Jun 2015 16:28:03 +0200, a écrit :

ACTION=="add", SUBSYSTEM=="leds", ENV{DEVPATH}=="*/input*::capslock", ATTR{trigger}="kbd-ctrlllock"

works, however :)

Samuel

Hello,

The patch got into Linus' tree, so it will most probably get into Linux
4.2.  We should thus probably work on the console-setup support for it
already, it won't hurt.

So the idea is that console-setup can configure which modifier lights
which LED, by first emitting udev rules such as this:

ACTION=="add", SUBSYSTEM=="leds", ENV{DEVPATH}=="*/input*::capslock", ATTR{trigger}="kbd-ctrlllock"

for the subsequently-plugged keyboards, and then do the echo by hand for
existing keyboards, similarly to this:

for i in /sys/class/leds/input*::capslock/trigger
do
	echo kbd-ctrlllock > $i
done

The physical LED names (capslock in the example above) are:

numlock (defaults to kbd-numlock)
capslock (defaults to kbd-capslock)
scrolllock (defaults to kbd-scrolllock)
compose
kana (defaults to kbd-kanalock)
sleep
suspend
mute
misc
mail
charging

and the trigger names (kbd-ctrlllock in the example above) are:

(the 4 legacy LED states)
kbd-scrollock
kbd-numlock
kbd-capslock
kbd-kanalock

(the 8 layout modifiers)
kbd-shiftlock
kbd-altgrlock
kbd-ctrllock
kbd-altlock
kbd-shiftllock
kbd-shiftrlock
kbd-ctrlllock
kbd-ctrlrlock

Anton, do you have all the informations you need to match that with the
xkb data?

Samuel

At this point I had the feeling I understood everything I needed.

But here, I don't understand what matching with xkb data you mean?

I have the following questions:

1. Is there a packaged Debian kernel with this functionality I can use?

2. Suppose the new keyboard layout requires a trigger different from
kbd-ctrlllock (because the user used KMAP in /etc/default/keyboard or
installed console-setup-mini).  I can echo the new trigger for the
existing keyboards, but what about the udev rules?  Can they change on
the fly?  Or maybe there is some way not to hardcode the trigger in the
udev rule but read it from a separate file each time the rule activates?

BTW, at the moment I think it will be best if I write a script kbd_leds
and propose it for inclusion in the console utilities package 'kbd'.
Definitely, this is a functionality useful not only for console-setup
users.  Then console-setup will be able to use the combination
kbd_mode+loadkeys+kbd_leds in order to configure the keyboard.

Anton Zinoviev

Anton Zinoviev, le Thu 02 Jul 2015 19:39:06 +0300, a écrit :

I mean matching the LED names from xkb with the LED names from Linux

Not yet.

You can just overwrite the udev rule with the new value.

Ah, yes, that can be useful indeed.

Samuel

Hello,

Anton Zinoviev, le Thu 02 Jul 2015 19:39:06 +0300, a écrit :

It happens that Ben had already uploaded rc8 in experimental:
linux=4.2~rc8-1~exp1
so you can use that for testing.

Samuel

Dear Customer,

Your parcel was successfully delivered February 17 to UPS Station, but our courier cound not contact you.

Postal label is enclosed to this e-mail. Please check the attachment!

Thank you for your assistance in this matter,
Oscar Mcintosh,
UPS Chief Support Manager.

Pinging the bug - as of Debian Buster, caps lock is still broken in
the console. The fix mentioned in #109 works, and it looks like the
necessary led-trigger support should be in all relevant kernels by
now.

I think the udev rule could be added to the console-setup package now ?

Thanks,

Hi,

this bug is still present in Debian/Ubuntu. I noticed that in ckbcomp
broken_caps is set to 1 even when the keycode $v is <100, triggering the
ControlL_lock replacement. IIUC the 'gt' is a string operator that
should be replaced with '>' at print_vector():

                if ($v != $c && $v gt 0x7f) {
                    $broken_caps = 1;
                }

Also, is the udev rule going to be part of the next release of
console-setup?

Thanks,

Victor

This issue still exists in current sid and bookworm.
Is that still this issue?

Is there more info you need from my system?

Control: found -1 1.236

I confirm that at least the CapsLock LED issue still occurs.
In grub, the LED works as expected, but it no longer works when
I need to type the passphrase to unlock the disk.

Under X11, the CapsLock LED works again.