Bug#514464: caps lock led does not show up
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
Bug#514464: caps lock led does not show up
Hello, Anton Zinoviev, le Thu 02 Jul 2015 19:39:06 +0300, a écrit : > 1. Is there a packaged Debian kernel with this functionality I can use? The 4.2 kernel went out today. It happens that Ben had already uploaded rc8 in experimental: linux=4.2~rc8-1~exp1 so you can use that for testing. Samuel
Bug#514464: caps lock led does not show up
On Thu, Jun 25, 2015 at 05:41:12PM +0200, Samuel Thibault wrote: The patch got into Linus' tree, so it will most probably get into Linux [... skipping some long comprehensible explanation ...] At this point I had the feeling I understood everything I needed. Anton, do you have all the informations you need to match that with the xkb data? 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514464: caps lock led does not show up
Anton Zinoviev, le Thu 02 Jul 2015 19:39:06 +0300, a écrit : Anton, do you have all the informations you need to match that with the xkb data? But here, I don't understand what matching with xkb data you mean? I mean matching the LED names from xkb with the LED names from Linux I have the following questions: 1. Is there a packaged Debian kernel with this functionality I can use? Not yet. 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? You can just overwrite the udev rule with the new value. 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. Ah, yes, that can be useful indeed. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514464: caps lock led does not show up
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514464: caps lock led does not show up
Samuel Thibault, le Thu 11 Jun 2015 10:08:09 +0200, 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.
Except that it makes my system unbootable. For whatever reason, systemd
indefinitely waits for the network to become available...
Samuel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514464: caps lock led does not show up
Hello,
Anton Zinoviev, le Tue 09 Jun 2015 19:03:39 +0300, a écrit :
On Tue, Jun 09, 2015 at 04:17:23PM +0200, Samuel Thibault wrote:
Dmitry Torokhov, le Mon 08 Jun 2015 14:43:07 -0700, a écrit :
If user wants all keyboards to light up CapsLock LED when VT state locks
CtrlL modifier they need to write a udev rule or similar to set up
kbd-ctrlllock trigger for all appearing input%::capslock LED class
devices.
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,
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?
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514464: caps lock led does not show up
Samuel Thibault, le Thu 11 Jun 2015 16:28:03 +0200, a écrit :
Samuel Thibault, le Thu 11 Jun 2015 10:08:09 +0200, 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.
Except that it makes my system unbootable. For whatever reason, systemd
indefinitely waits for the network to become available...
ACTION==add, SUBSYSTEM==leds, ENV{DEVPATH}==*/input*::capslock,
ATTR{trigger}=kbd-ctrlllock
works, however :)
Samuel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514464: caps lock led does not show up
Hello, Samuel Thibault, le Thu 05 Feb 2009 12:39:08 +0100, a écrit : 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. Dmitry Torokhov, le Mon 08 Jun 2015 14:43:07 -0700, a écrit : If user wants all keyboards to light up CapsLock LED when VT state locks CtrlL modifier they need to write a udev rule or similar to set up kbd-ctrlllock trigger for all appearing input%::capslock LED class devices. 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: Having such virtual multiplexing object just adds complexity and is hard to untange (see /dev/input/mice and all the issues we had with synaptics driver trying to exclude it's data stream from it). Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514464: caps lock led does not show up
On Tue, Jun 09, 2015 at 04:17:23PM +0200, Samuel Thibault wrote: Dmitry Torokhov, le Mon 08 Jun 2015 14:43:07 -0700, a écrit : If user wants all keyboards to light up CapsLock LED when VT state locks CtrlL modifier they need to write a udev rule or similar to set up kbd-ctrlllock trigger for all appearing input%::capslock LED class devices. 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, 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
