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

[Lennart Poettering]

On Wed, 06.02.13 16:36, Kay Sievers (kay at vrfy.org) wrote:

> 
> On Wed, Feb 6, 2013 at 4:03 PM, David Herrmann
> <dh.herrmann at googlemail.com> wrote:
> 
> > 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.
> 
> We should really step back from doing anything non-essential with VT
> settings from the systemd core tools. That meas things which are not
> needed to log in, or type in a password. The fonts and keymaps are
> obviously essential and needed, LEDs, key states, repeat rates are not
> so much.
> 
> If people need that they should hook up some other additional tool.
> It's basically the same rule we have for other fancy things too like
> hwclock and such. Systemd should not make any promises here, if we
> cannot deliver a reliable an supportable solution here with what the
> kernel offers us here.
> 
> > 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.
> 
> Right, I personally know too much stuff about VCs, stuff I never
> wanted to know, and wasted too much time with it.
> 
> All the stuff we offer in the core, we need to support properly and we
> will get bugs for it, and will need to debug and fix them. I really
> don't want to do that.
> 
> In short: I'm against adding *any* new non-essential features to
> vconsole in its current state.

So, my 5¢ on this are basically: I think it makes sense to have a
setting for global system defaults like this, regardless which clients
might later on make use of this, whether it's x11, wayland, kmscon,
plymouth or good old VT. The setting is trivial enough so that such a
setting would make sense on whatever might be running later on, and at
least in theory there is no real problem in hooking up these various
consumers to this file for the implied system defaults.

That said, I am very much unwilling to merge something that is known to
be broken, and to negatively impact X11 or any other fancier low-level
client. We have to support this stuff after all, and you can believe me:
the idea that I'd have to patch the fuckup that is the kernel console
logic just because we added a feature to userspace that sometimes fucks
things up for X11 is everyhing but something I am looking forward to.

However, I think the implementation on VT might not be entirely
impossible. One way that appears acceptable to me is maybe by checking
explicitly if the VT is in use as proper TTY before doing the LED
change. Or in other words: if X11, or Wayland, or kmscon are running on
a VT the code would have to just skip it. Not entirely sure how to best
make that happen though...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.