gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard

[Andreas Henriksson]

Hello Anton Zinoviev.

Again thanks for your followup with useful information.

On Sat, Feb 20, 2016 at 05:02:28PM +0300, Anton Zinoviev wrote:
> Bug #765343 is related to this one.

ACK.

> 
> On Fri, Feb 19, 2016 at 08:33:08PM +0100, Andreas Henriksson wrote:
> > 
> > On Fri, Feb 19, 2016 at 08:52:25PM +0300, Anton Zinoviev wrote:
> > 
> > > The modifying program, however, has to leave everything else intact:
> > > assignments of unknown variables, commented lines and blank lines.
> > 
> > I don't think this is good advice however.
> 
> The unknown variables really have to be preserved because we have no idea what 
> variables will be used by future versions of console-setup, X or other keyboard 
> using applications. As for the comments, they should be preserved because this is 
> not some registry of values like Gconf or the registry of Microsoft. 

In my view you're whe one arguing that it *should* work as the Windows
Registry.

Please note that the key difference between GConf (which btw is
deprecated) and Windows Registry is that GConf has a well defined schema
while Windows Registry you just pile on stuff and noone ever cleans
it up and you can't reset it without reinstalling.

You're arguing that we should just pile on more and more in
/etc/default/keyboard, while preserving everything a program
doesn't know about, while also not being able to start from
scratch because only d-i knows how to make a proper default
configuration thus a reinstall would be needed.

In my view a (sane) configuration file is something which
only contains configuration (no defaults, etc which is in
the program itself). When you reconfigure you write out
the minimal set of options you want to set up different
from the default. You carry settings just for the sake of it
in the configuration file.

Anyway, this is getting pretty meta-discussion like here
so we should probably just say that it's good that we
both know we have different views on a couple of things here.

> This is a configuration text file maintained manually by the system
> administrator.

(Except manual labour is becoming less and less common. After all we use
computers to automate things.)

>  
> > Consider the highly theoretical case of a very simple configuration
> > program only dealing with XKBLAYOUT and leaving other fields intact,
> > eg. XKBVARIANT.
> 
> Well, XKBVARIANT is not exactly an unknown variable. :)
> 
> > > XKBMODEL has no default value (at least in console-setup).  It should
> > > always be present and never as empty value.
> > 
> > (If there's no default, how can it be expected to never be empty?!
> 
> Debian installer puts there a sensible value.
> 
> > Also empty seems to be perfectly acceptable by/for X atleast.)
> 
> I don't know what exactly X does when XKBMODEL is an empty string.  On most 
> architectures there is a default model which works in most cases (but some 
> multimedia and game keyboards require a specific model to be fully supported).  
> On hppa it is impossible to have any default model but X doesn't run on hppa...
> 
> > > XKBOPTIONS is not necessary in which case empty value is assumed.
> > > Notice however that XKBOPTIONS should never be empty (or missing) when
> > > the keyboard is for a non-Latin language.
> > 
> > Thanks for this advice. I think it would be great if we could formalize
> > the expectations programs parsers (and writers) of /etc/default/keyboard
> > can make on a wiki.debian.org page or similar....
> 
> When I wrote 'XKBOPTIONS should never be empty' I didn't mean some program 
> expects it not to be empty.  I only meant that the user is going to be very upset 
> if his XKBOPTIONS are removed.

All I can say it that such a person should not be reconfiguring the
system keyboard setup with gnome-control-center then. Also I kind
of doubt that GNOME doesn't already have very good internationalisation
support, but I personally don't have any experience with non-latin setups.

>  
> > I'm thinking a table with all known variables listed plus if they're
> > optional, default value, .... what else?
> 
> Try 'man keyboard'.  Then ask me, if there are any questions. :)

Sorry, but after reading this manpage a couple of times I'm still confused.

There's no explicit mention of mandatory/optional so I imagined,
based on this bug dicussion about XKBMODEL always needing to be present,
that anything that was not explicitly mentioned as optional was mandatory.
Then I looked at the examples at the bottom of the manpage....
Please note how none of them includes XKBMODEL!

Are the manpage examples broken or what am I missing?

>  
> > (Once it's more clear to me I'll volunteer trying to improve the debian
> > systemd/localed patch to follow your advice when I find time, unless someone
> > else beats me to it. Main question would be the one in paranthesis above.)
> 
> As for the systemd/localed, the only problem I can see there is that it removes 
> the comments from the file.  Other than that it seems ok -- it preserves the 
> values of the unknown variables and it works correctly with spaces.
> 
> > > Since gnome-control-center doesn't provide means to configure
> > > XKBOPTIONS, I suppose it will be best if it leaves the current value
> > > unchanged (this is debatable).
> > 
> > As discussed above I don't really agree and appreciate this being
> > debatable. ;)
> 
> I haven't made tests but I suppose that Gnome ignores the system-wide keyboard 
> layout and always sets a user specific layout.  If no other working environments 
> are used (graphical or console based), then few people are going to miss the 
> value of XKBOPTIONS because most of these options are not necessary to type the 
> username and the password.  This also has the additional benefit, also debatable ;)
> that the keyboard at the login window will be more or less standard. For example 
> the keys CapsLock and Control are not going to be swapped.
> 
> On the other hand, if we want to be able to configure system-wide keyboard layout 
> not only for Gnome, then the only realistic solution for Debian based systems I 
> can see is to keep XKBOPTIONS unchanged.  This is so because console-setup puts 
> there a very sensible value and it is more or less layout independent. But I am 
> not sure that we really want to be able to configure system-wide keyboard layout 
> for non-Gnome environments using gnome-control-center.  There are other more 
> powerful programs to do this.
> 
> Therefore, despite the title of this bug report, we can consider it fixed if 
> gnome-control-center doesn't remove the variable XKBMODEL.  Deleting XKBOPTIONS 
> is acceptable.
> 
> In case it is difficult to preserve the existing value, you can use 'pc105' as a 
> default value.  Alternatively, the following table with default values can be 
> used:
[...]

I was initially thinking that hardcoding pc105 would be very ugly, but
given your explanation now I think it sounds like a sane solution. Last
time I spoke with someone interested in Linux on amiga it was mentioned
that running X on it was not an interesting usecase at all, thus I
highly doubt running GNOME on top of that is either. ;P
I also wonder if a person interested in retro-computing would even
consider using systemd on it rather than a more retro alternative...
In other words, maybe even for systemd it's not very interesting
to consider something ever using anything else than XKBMODEL=pc105.

(Still wondering though if we really need to hardcode an output
of XKBMODEL=pc105 into /etc/default/keyboard. If this is the default we
shouldn't need to include it in the configuration file IMHO. And as
mentioned the examples of keyboard(5) suggest it's not needed....)

Regards,
Andreas Henriksson