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

[Anton Zinoviev]

Bug #765343 is related to this one.

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.  This is a 
configuration text file maintained manually by the system administrator.
 
> 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.
 
> 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. :)
 
> (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:

Architecture  Subarchitecture Model
-----------------------------------
m68k          atari           ataritt
m68k          mac             macintosh_old
m68k          Other           pc105
powerpc       amiga           amiga
powerpc       Other           pc105
Other                         pc105

Notice that m68k is no longer supported by Debian.  Powerpc is supported but I 
don't know how many people use Gnome on Amigas...

In this table the architecture is the string obtained by 'dpkg 
--print-architecture'.  On m68k the subarchitecture can be obtained in this way:

        line=`sed -n 's/^Model.*: *//p' /proc/hardware`
        if [ "$line" = '' ]; then
            echo unknown
            return 0
        fi
        subarch=`echo $line|tr A-Z a-z`
        case "$subarch" in
            *macintosh*|*powermac*|*powerbook*|*power*|*imac*|*powermac1*)
                subarch=mac
                ;;
            *atari*)
                subarch=atari
                ;;
            *)
                subarch=Other
                ;;
        esac

On powerpc the subarchitecture can be obtained in this way:

        line=`sed -n 's/^platform.*: *//p' /proc/cpuinfo`
        if [ "$line" = PS3 ] || [ "$line" = Cell ]; then
            subarch=`echo $line|tr A-Z a-z`
        else
            line=`sed -n 's/^machine.*: *//p' /proc/cpuinfo`
            if [ "$line" = '' ]; then
                echo unknown
                return 0
            fi
            subarch=`echo $line|tr A-Z a-z`
        fi
        case "$subarch" in
            *amiga*)
                subarch=amiga
                ;;
            *)
                subarch=Other
                ;;
        esac

> For other (unknown) values the systemd patch would need to be changed as
> it currently only reads out a fixed set of variables (those matching the
> known set included in the dbus apis) and unlinks the existing file on
> writing out new settings.

It preserves the unknown variables, so there is no need to do anything.
 
> Thanks for looking into this and I also think we should continue that
> discussion in a separate bug report to keep focus on the more important
> and practical problem in this bug report.

Done: #815244.

Anton Zinoviev