https://bugzilla.redhat.com/show_bug.cgi?id=966799
--- Comment #19 from Peter Hutterer peter.hutterer@redhat.com --- (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.