I think this is down to the wrong geometry being used - pc101, where it should be pc102. I am trying to figure out where the association between layout and geometry is done (and at what layer, GNOME or xkb). GNOME doesn't appear to offer any potential for configuring the geometry directly.

So here's what I've figured out on this so far.

The problem is clearly the X keyboard model / geometry (geometry is a property of the model). When you look at GNOME's keyboard selector thing, the model it illustrates is the pc104 model: it has the two super keys and the 'menu' key, but it does not have the key between left shift and Z which is the backslash and broken pipe key on UK keyboards. (This key is named <LSGT> in /usr/share/X11/xkb/geometry/pc , the file that actually defines the pc104 and pc105 models).

Clearly, for the reporter, this is also the model / geometry that is actually being used (it's not just a bug in GNOME's logic for rendering the illustration), because their \ key doesn't work.

So I went digging to see what various layers do about keyboard geometries.

AFAICS anaconda doesn't do anything with this any more, it just leaves it to other layers. All anaconda basically does is let you specify an X layout (not model) and layout switcher key, which it passes into the Xorg config snippet /etc/X11/xorg.conf.d/00-keyboard.conf that does not say anything about model (I just tested that an F19 Beta RC4 install with the US and UK keyboard layouts selected, and a layout toggle key combo specified, writes a 00-keyboard.conf that specifies the two layouts and the toggle, but does not specify a model).

systemd-localed inherited system-config-keyboard's mapping between kbd and xkb keyboards, as the file /usr/share/systemd/kbd-model-map . This file does specify an 'xmodel' for each layout. For almost all layouts, including uk/gb, it specifies pc105. So far as I can tell, localed only reads kbd-model-map (as the variable SYSTEMD_KBD_MODEL_MAP) in the functions convert_vconsole_to_x11 and convert_x11_to_vconsole. convert_vconsole_to_x11 looks like it does have the potential to set the model. Ultimately, keyboard configuration set by systemd-localed is written into /etc/X11/xorg.conf.d/00-keyboard.conf - i.e., it's setting things at the X level. So if nothing tells localed what model to set, and it doesn't have some kind of fallback to always set a model if one is not specified, then we move on the the X level defaults.

The X server code has a compile-time parameter for the default model: --with-default-xkb-model , which sets the variable XKB_DFLT_MODEL . This has been pc105 since this patch in Dec 2009:

http://lists.x.org/archives/xorg-devel/2009-December/004254.html

Checking our X server package out of git and running 'fedpkg prep', it looks like we are not changing this. So that layer seems OK.

So far as I can tell, xkb (xkeyboard-config) doesn't have any smarts for trying to associate layouts with geometries: it strictly just defines layouts and geometries and applies one to the other. If a layout specifies the symbols for a key that is not actually present in the model in use, the key is just ignored.

I have poked through the code at the GNOME level till my eyes bled, but I can't find any point at which it actually sets the model. Basically you start at gnome-control-center/panels/region/cc-input-chooser.c and work your way through, and gnome-settings-daemon/plugins/keyboard/gsd-keyboard-manager.c , gnome-desktop/libgnome-desktop/gnome-xkb-info.c and all of libgnomekbd are possibly involved, but so far as I can make out, if anything explicitly sets a model it's gnome-desktop/libgnome-desktop/gnome-xkb-info.c , and that does:

#ifndef XKB_MODEL
#define XKB_MODEL "pc105+inet"

so that looks right. At this point I'm kinda stuck, and can't figure out what might be going wrong here. I don't think I have a pc105 keyboard here, which makes it a bit hard to test myself (I can't find a way to 'inject' a keycode into the stack; the evdev keycode for the LSGT key is 94, so that's what we'd want to use if there is a way to do that). But I can't immediately see what's going wrong here.

So, things that might help figure this out:

* Does the key work if you run 'localectl set-x11-keymap uk pc105' - which should write an explicit line:

Option "XkbModel" "pc105"

to /etc/X11/xorg.conf.d/00-keyboard.conf - and then reboot or restart X?

* Does the key work at the virtual consoles - ctrl-alt-f2, ctrl-alt-f3 etc?

* Does the key work if you do a KDE or Xfce install?

* Does the key work if you do a GNOME install of F16 or F17 (or just boot an F16/F17 live image)?

Thanks!

I note that the F19 MATE spin's Keyboard Preferences dialog has a 'Keyboard model' setting. By default it shows as "Unknown" and appears to actually be pc104: it acts as the OP describes GNOME acting, if you add the UK layout, the LSGT key is missing. But if you change "Keyboard model:" to "Generic 105-key (Intl) PC", the LSGT key does indeed show up in the UK layout. That rather indicates that, indeed, the problem is that _something_ in the stack is setting the default model to pc104 (and GNOME doesn't have any option to change this, so you can't recover).

That MATE setting appears to set the gsettings key org.mate.peripherals-keyboard-xkb.kbd .

As far as I can tell, 'localectl set-x11-keymap uk pc105' and then reboot does indeed appear to fix the problem: GNOME illustration of the UK keyboard layout then includes the LSGT key. That again tends to confirm the belief that the problem here is that something somewhere is making our 'default' model, when none has been explicitly configured at the desktop or X level, pc104 rather than pc105.

Wow, blast from the past, I just grabbed the Fedora 14 live image and tried that. It behaves a lot like the F19 MATE spin (good job MATE, I guess :>) - the default model appears to be pc104, and it has the old-style Keyboard Preferences capplet with "Keyboard model: Unknown", just like MATE does now, and if you switch that to "Generic 105-key (Intl) PC", the extra key appears in the illustrated layout.

If you boot any Fedora 19 live image - or, for that matter, the F14 one - and run 'setxkbmap -print', you get this:

xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+inet(evdev)"	};
	xkb_geometry  { include "pc(pc104)"	};
};

note the geometry is pc104. So I guess, if we consider this broken at the X layer, it's been broken for a long time, unless I'm misreading things. Obviously, there is potential here for anaconda to try and set an 'appropriate' default model for different layouts, and for desktops to do something similar; perhaps we should add the most common model for each layout as information in langtable. But it does seem like X _wants_ the default model to be pc105, and that may not be working.

Up until F18, this would have been disguised by system-setup-keyboard , which used that kbd-model-map data; both anaconda and s-c-k configured the keyboard through s-s-k, so when you set a keyboard layout with one of those, a model would always have been explicitly written into /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf . Even on the F14 live image, a /etc/X11/xorg.conf.d/00-system-setup-keyboard.conf which specifies the pc105 model is present. So, my theory now is that at the very bottom of the stack, the X server has been defaulting to pc104 geometry all along, and somehow that XKB_DFLT_MODEL setting in the X server isn't affecting that, but we never really noticed in Fedora up till Fedora 18 because s-s-k disguised it.

hmm, okay, so I figured out some more about this. I think the above theory is incorrect (though I had fun!) - now I dig into xkb some more, it looks like the geometry setting isn't really all that important. It does affect the GNOME layout preview render, as described in comments #5 and #6, but I think (and GNOME team confirms) that that's probably just a visual thing and in fact shouldn't affect actual typing. As mentioned at http://pascal.tsu.ru/en/xkb/setup.html , "This description XKB doesn't use by itself but it can be useful for applications like xkbprint that draw keyboard images."

Also, Rui Matos says that he has a pc105 keyboard and the 'extra' key works for him. So, clearly, there must be more to this.

Onyeibo, can you post the output of 'setxkbmap -print' on your system? And I guess I'd still be interested in whether that 'localectl' command fixes things after an X restart or reboot, though now I don't _think_ it should.

It would also be useful to know what output you get if you run 'xev' and press the extra key.

localectl:
----------
System Locale: LANG=en_GB.UTF-8
       VC Keymap: uk
      X11 Layout: gb
       X11 Model: pc102


setxkbmap -print:
-----------------
setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+gb+us:2+inet(evdev)+level5(lsgt_switch_lock)"	};
	xkb_geometry  { include "pc(pc102)"	};
};


xev session:
------------

KeymapNotify event, serial 33, synthetic NO, window 0x0,
    keys:  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

PropertyNotify event, serial 33, synthetic NO, window 0x2200001,
    atom 0x14c (_NET_WM_STATE), time 689370, state PropertyNewValue

PropertyNotify event, serial 33, synthetic NO, window 0x2200001,
    atom 0x14c (_NET_WM_STATE), time 689390, state PropertyNewValue

KeyPress event, serial 33, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 691559, (367,321), root:(369,408),
    state 0x0, keycode 94 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 691683, (367,321), root:(369,408),
    state 0x20, keycode 94 (keysym 0xfe13, ISO_Level5_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 694937, (367,321), root:(369,408),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 695097, (367,321), root:(369,408),
    state 0x1, keycode 94 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 695278, (367,321), root:(369,408),
    state 0x21, keycode 94 (keysym 0xfe13, ISO_Level5_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 695369, (367,321), root:(369,408),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 696378, (367,321), root:(369,408),
    state 0x0, keycode 94 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 696615, (367,321), root:(369,408),
    state 0x20, keycode 94 (keysym 0xfe13, ISO_Level5_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 697094, (367,321), root:(369,408),
    state 0x0, keycode 94 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 697322, (367,321), root:(369,408),
    state 0x20, keycode 94 (keysym 0xfe13, ISO_Level5_Lock), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

EnterNotify event, serial 36, synthetic NO, window 0x2200001,
    root 0x82, subw 0x0, time 698822, (177,10), root:(179,97),
    mode NotifyNormal, detail NotifyAncestor, same_screen YES,
    focus YES, state 0

KeymapNotify event, serial 36, synthetic NO, window 0x0,
    keys:  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0 

Strange, the X11 Model from localectl changed back to pc102 after I had set it to pc105.

So it turns out the model/geometry thing doesn't actually matter much - the only thing it affects is actually the keyboard preview, so that was leading me up the garden path :)

Your problem looks to be this:

xkb_symbols   { include "pc+gb+us:2+inet(evdev)+level5(lsgt_switch_lock)"	};

I don't know where it's getting that "level5(lsgt_switch_lock)" from, but that's the problem - if you look at the xev output, keycode 94 (which as we established above is the keycode of the key in question) is being translated to ISO_Level5_Shift then ISO_Level5_Lock . So it is in fact doing something, it's just not the thing you expect, and not something that has an obvious effect.

Can you run 'gnome-tweak-tool', go to Typing, and see if "Key to choose 5th level" is set to the first choice - "<Less/Greater> chooses 5th level, locks w..."? If so, that's your problem: unset it. If not, please post or attach the contents of /etc/X11/xorg.conf and all files in /etc/X11/xorg.conf.d . Thanks!

unsetting "level5(lsgt_switch_lock)" using dconf-editor fixed it.

Yup, glad we got that one. But now the question is how it got that way...

Adjusting summary for what we know so far: the reporter had the XkbOption 'lv5:lsgt_switch_lock' set in the org.gnome.desktop.input-sources.xkb-options gsettings key, but I don't know why. I can't see anything in the xkb rules that could lead to it being set inadvertently, so I don't know if it somehow got set by anaconda and then vacuumed up by g-s-d, or if g-s-d somehow set it, or what...

the reporter says he did not have gnome-tweak-tool installed at all, so it doesn't seem like he could have accidentally set it in there.

To be clear. Is this happening on a new install or was this system upgraded? Even if it's a new install, did you use an existing user account from previous versions?

Also, what's the content of  /etc/X11/xorg.conf.d/00-keyboard.conf ? Do you have any other X conf files lying around in that directory?

It happened on a new Fedora-18 installation on my new laptop.  I have had to reinstall F19 using the old /home anyways but this setting suddenly occurred somewhere between F17 or F18 on a number of my systems

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" "gb"
        Option "XkbModel" "pc102"
EndSection

The crucial question is: does it happen when you log in to an empty user account? I.e. a freshly created one?

And there are no other X configuration files besides that?

I'll have to try that out with a fresh candidate (machine).  Keep this open.

(In reply to Adam Williamson from comment #9)
> hmm, okay, so I figured out some more about this. I think the above theory
> is incorrect (though I had fun!) - now I dig into xkb some more, it looks
> like the geometry setting isn't really all that important. It does affect
> the GNOME layout preview render, as described in comments #5 and #6, but I
> think (and GNOME team confirms) that that's probably just a visual thing and
> in fact shouldn't affect actual typing. As mentioned at
> http://pascal.tsu.ru/en/xkb/setup.html , "This description XKB doesn't use
> by itself but it can be useful for applications like xkbprint that draw
> keyboard images."

evdev still uses the "evdev" model, which was hidden in xkeyboard-config 1.9. it resolves to pc104 for geometry which is technically correct for the 'us' default that evdev is configured to. this is where the pc104 comes from if no model is explicitly configured. aside from that: geometry is purely for drawing the keyboard, it's only parsed by the server for data-correctness but not for actual content. 

what matters in keyboard configuration are the keycodes, and if you use evdev you get all of them anyway, regardless of the physical keyboard (the kernel abstracts the hardware-specifics away).

(In reply to Adam Williamson from comment #2)
> which makes it a bit hard to test myself (I can't find a way to 'inject' a
> keycode into the stack; the evdev keycode for the LSGT key is 94, so that's
> what we'd want to use if there is a way to do that). 

Install evemu and get a set of devices from https://github.com/whot/evemu-devices
you can then either record some events and change the keycodes manually, or use evemu-event to play a single event. also, remember: X keycodes are kernel keycode + 8.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.