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

[David Herrmann]

Hi Matthias

On Wed, Feb 6, 2013 at 3:12 PM, Matthias Berndt <matthias_berndt at gmx.de> wrote:
> No. I had seen a similar hint toward the end of the console_ioctl man page and
> decided to ignore it. These ioctls have been around forever, tools like
> setleds(1) rely on them. We know how Linus feels about breaking userspace, so
> they're not going to go away. Also, to my knowledge there's no other way to do
> this. One could launch setleds(1) instead and rely on it being changed in the
> unlikely event that these ioctls go away. That would however require patching
> setleds(1) in order to implement the optimisation suggested by Lennart.

Well, the effect on user-space (if you remove them) is really small
and doesn't break any ABI. You simply get an error code on ioctl()
which is probably ignored by most programs in this case. So I think it
isn't _that_ unlikely that they might be removed.

>> 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.
> I've observed that when you switch from an X vt with NumLock off to a text vt
> with NumLock on, the LED will not light up, but the numpad keys generate
> numbers nevertheless -- the caching you've mentioned may be the reason for
> that.
> Anyway, this happens regardless of whether you enable NumLock with the
> keyboard key or with the ioctl, so this issue, aside from being cosmetic, is
> orthogonal to the patch at hand.

The problem Lennart mentioned is what happens if you call setleds
while the xserver is running. I just checked XKB and there are two
different behaviors.

1) XKB notices it and updates its internal keyboard state accordingly

2) XKB ignores LED updates and you basically hose the keyboard LEDs this way.

The second one is btw. the default for new applications. So XKB
updates LEDs on VT wakeup according to its state but never ever reacts
on LED changes from the input-device itself (why would it?).

So calling setleds while an xserver/etc. is running is buggy.

The problem is, XKB updates LEDs according to its internal modifier
state, but the kernel (KBD) updates its modifier state according to
keyboard LEDs.

I actually don't care that much whether this option gets introduced or
not. The race-condition is pretty hard to trigger and even if you
trigger it, it doesn't cause any big problems but only wrongly lit
LEDs.
But the VT layer is just so broken that it feels wrong to introduce
more bogus features that don't work well with the rest of the system.

Regards
David