This list is read from /usr/share/X11/xkb/rules/base.lst. There's no evdev there. Dunno, if you feel that it should be listed, then please reassign this to xkeyboard-config.

On my machine, I get:

$ setxkbmap -query
rules:      evdev
model:      pc104
layout:     us
options:    ctrl:nocaps

I don't think there is "evdev" model. Maybe it was a bug setxkbmap?

I'll close this bug now.

(In reply to Jan Synacek from comment #2)
> On my machine, I get:

then the "correct" resolution would be 'WORKSFORME' or 'INSUFFICIENT_DATA', not 'NOTABUG' - the fact that you cannot reproduce doesn't mean there isn't a bug

current results on my machine with xorg-x11-xkb-utils-7.7-16.fc23.x86_64 and systemd-222-8.fc23.x86_64:

$ setxkbmap -query
rules:      evdev
model:      evdev
layout:     cz
variant:    qwerty
options:    terminate:ctrl_alt_bksp
$ localectl list-x11-keymap-models | grep evdev ; echo $?
1

(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> This list is read from /usr/share/X11/xkb/rules/base.lst. There's no evdev
> there. Dunno, if you feel that it should be listed, then please reassign
> this to xkeyboard-config.

well, how could I know if it should be listed?

I just want the output to be consistent - if 'list-x11-keymap-models' is supposed to list available models then how is that possible that the actual model is set to something not listed as available? ... but I do not know if the bug is in the list that it is missing that value, or in the value that it shouldn't be something not on the list

anyways, reassigning to xkeyboard-config as suggested

(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> This list is read from /usr/share/X11/xkb/rules/base.lst.

for correctness, you should read evdev.lst though the two files have the same content.

Karel - do you have some xorg.conf.d snippets? can you attach your Xorg.log? we switched evdev to pc105 a while ago in the server and the evdev driver, so I'm wondering where this setting comes from.

Aside from that, it's not really a bug, the setxkbmap output is not trustworthy. The RMLVO keyboard specification is just the entry point to switch to the actual format that xkb uses, see [1] for more details.

The evdev rule has a couple of catchalls, look at /usr/share/X11/xkb/rules/evdev in e.g. the !model = keycodes section. The last line there is:
  *             =       evdev

this means "any model maps to the evdev keycodes". You can run setxkbmap -model "foo" and now you've set the model "foo" even though it doesn't exist. You got the evdev keycodes and triggered a couple of other generic matches, but specifying foo neither helped nor made it worse. The same applies to evdev - there is no real evdev model.


[1] http://who-t.blogspot.com.au/2008/09/rmlvo-keyboard-configuration.html

(In reply to Peter Hutterer from comment #4)
> Karel - do you have some xorg.conf.d snippets?

a bit late but anyways ...

$ cat /etc/X11/xorg.conf.d/00-keyboard.conf 
# Read and parsed by systemd-localed. It's probably wise not to edit this file
# manually too freely.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "cz"
        Option "XkbModel" "evdev"
        Option "XkbVariant" "qwerty"
        Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

> can you attach your Xorg.log?

guess there's no need to as we see "evdev" as "XkbModel" in the configfile ...

> Aside from that, it's not really a bug, the setxkbmap output is not
> trustworthy.

well ... such behaviour is very confusing

if something is supposed to tell me what the settings are and it reports nothing, it is quite hard to tell if the settings are correct unless you have deep knowledge of the subject that you cannot expect from ordinary users ...

(In reply to Karel Volný from comment #5)
> > Aside from that, it's not really a bug, the setxkbmap output is not
> > trustworthy.
> 
> well ... such behaviour is very confusing

agreed, but at least within X there isn't much we can do. setxkbmap's (and the server's) approach to handling RMLVO dates back to when we only had one single keyboard (pre-2007). Fixing the various tools is generally possible, but no-one has put the effort in, there's just not that much benefit.

> if something is supposed to tell me what the settings are and it reports
> nothing, it is quite hard to tell if the settings are correct unless you
> have deep knowledge of the subject that you cannot expect from ordinary
> users ...

and this summarises the problem nicely. setxkbmap doesn't tell you the settings, it merely tells you the value of an unrelated property that is set at server startup and (hopefully) by the tools changing the keyboard layout. keyboard layout configuration is lossy, once you load a layout you cannot go back to the RMLVO designation that created the layout.

the only way for setxkbmap to actually tell you the current setting would be to look at every key and match it up with a generated keyboard layout. given that thousands of combinations, that's not really viable.