[systemd-devel] [Patch] NumLock setting from vconsole.conf

[David Herrmann]

Hi Matthias

On Wed, Feb 6, 2013 at 12:51 AM, Matthias Berndt <matthias_berndt at gmx.de> wrote:
> Hi Lennart,
>
>> It should suffice to invoke your set_modifiers() function in some
>> wrapper function set_modifiers_on_all_vcs() which internally just runs
>> VT_GETSTATE and iterates over all allocated VCs. See
>> font_copy_to_all_vcs() for inspiration.
> Done. I've factored out the common code as an iterator.
>
>> I wonder what happens if X11 is currently active on the VC that the leds
>> setting is applied to. Ideally, the ioctl would just fail, or at least
>> not have any negative impact on X11 or not break it. Have you played
>> around with that, by any chance?
> The ioctls return 0 and don't affect X. After switching back to text mode, the
> changes do take effect.

How do you know that? Looking at the kernel code it seems that the
LEDs are immediately set with the keyboard_tasklet/kbd_bh. So if the
xserver doesn't grab the input devices, then this _can_ break the
xserver input handling if it caches these states. Or am I missing
something here?

The problem with these ioctl's is that they affect global keyboard
state. They don't modify the VT state but instead send LED_* events
directly to the hardware to modify hardware state. That is, every
other application currently using the keyboards will be affected by
this.

The kernel-code also says:
  /* the ioctls below read/set the flags usually shown in the leds */
  /* don't use them - they will go away without warning */
Did you try to investigate why these are supposed to go away?

The VT layer also caches led-states and updates them only if they
differ. However, if you manually change led-states via linux input API
then this cache will be invalid and the whole concept is broken. So I
think this API isn't really what we want here. Instead, you probably
want to modify all input devices manually instead. But then this
configuration option is at the wrong place.

All in all, it sounds nice to have this option at vconsole.conf, but
it affects _global_ state, not _local_ VT state so other users might
be really confused if they wonder why their Xserver starts with
NUMLOCK enabled and they cannot find the option to disable it (why
would one look into vconsole.conf to modify xserver or input
behavior?).

>> A minor optimization might be to suppress the KDSKBLED if no change has
>> been made. This might be useful to avoid SELinux AVCs or so in case
>> people have very strict policies and nothing set.
> Done. The KDGKBLED is also suppressed when nothing is to be set.

Regards
David