This bug doesn't seem to get much attention here, but the problem is actually pretty severe. Here are some of the threads, that it already spawned and it's easy to find more:

http://forums.fedoraforum.org/showthread.php?t=287827
https://bbs.archlinux.org/viewtopic.php?id=151926
http://ubuntuforums.org/showthread.php?t=2212688
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1243642

Some are marked as [SOLVED] but if you look at it, people mostly start using systemd suspend/resume hooks to set their keyboard config, which is not at all appropriate on a multiuser system.

Also in the ticket originating this breakage:
https://bugzilla.gnome.org/show_bug.cgi?id=674874
The maintainer expressed his intent to keep xmodmap support, but aparently forces conspired to get it dropped anyway.

In an even older launchpad ticket, that got auto-closed because nobody did anything about it, somebody mentioned that the reason for this was evdev getting reloaded on suspend/resume: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/289781

This suggests that the proper fix for this is saving evdev configuration before unloading, and restoring it later, hence this ticket should maybe be renamed and reassigned.

Please note, that this bug likely also affects a lot of people with special input devices, which are not very vocal on the various FLOSS pipes.

to make it very clear: xodmap is not a supportable interface

Sorry, that doesn't make anything clear to me, at all. Is there some documentation to this claim? Some writeup of the problems with xmodmap, that force you to break it for your users? AFAIR, gnome2 used to support xmodmap just fine. And what about the thing about evdev, that I dug out?

Besides: I'm not asking you to support xmodmap per se, I just want one of two things in order for my keyboard layout to stop breaking:

Either:

Preserve my customized keyboard layout across gnome-shell restarts and suspend-resumes, so that I can set my own layout on login and make it stick.

OR

Give me a reliable hook, that gets fired when my desktop unlocks or wakes up, so that I can override those resets.

bump.

Matthias's minimalist comment leaves much to be desired. Another fact: the ticket has been open for half a year. Something doesn't seem right...

Let me explain it a little more then:

An .xmodmap file contains 'random' reassignments of modifiers, keycodes, etc. These get injected directly into the X server, bypassing any configuration settings of the desktop, and thereby making it extremely hard to present a meaningful UI.

Personally, I don't care whether there's a "meaningful" UI or not... I just want to have a consistent mechanism for altering the keymap. Xmodmap was that mechanism for many years, but was recently broken.

Matthias, thanks for the explaination!

Stupid question, could gnome's keyboard infrastructure not just read the keyboard settings from X? If so, it could detect when it diverges from the one configured by gnome, make that fact known to the user and offer options. Couldn't it?

OTOH, I'd be perfectly willing to make this work myself, maybe make an extension out of it, but in all honesty, I'm having a hard time even finding documentation on the (js) extension API of gnome-shell, let alone judging whether the offered API suits my needs.
The most comprehensive piece of documentation, I found yet: http://mathematicalcoffee.blogspot.com.es/2012/09/gnome-shell-javascript-source.html

Also, I'm currently having a look at `global.screen.get_display();`, where can I find out about all the events, that i can `dsp.connect("$evt-name", function(e){})` to? Are those plain wrappers around X events?
Also, on a slightly related note, looking glass seems to take a modal keyboard focus. Is there also gnome repl that I can use while editing and browsing?

#5, you're making a claim about the function of .xmodmap files that I really wish you would reconsider. Those files are almost always *user-specified*. That means the users deliberately set those files that way, and might very well have good reasons for doing so. 

My use case is my AltGr key (which I use a lot) is under my thumb and right next to the key for a context menu (which I never ever want to use), so I am very often accidentally hitting it, pulling up an unwanted menu, and accidentally deleting a block of text before I realize what's happening. However, I can also easily imagine use cases (say, for differently-abled users who might need to move keymappings around to something custom) that are much more justifiable than mine, and deliberately resetting those users' keyboards, because Reasons, seems to me … well, not a very positive way to interact with users. 

Having a keyboard constantly reset itself to an unwanted mapping silently is infuriating, and "the devs want to have more control over how the UI works" does not come across to me as (to put it mildly) a very tenable reason for overriding user-specified UI settings and giving users no other meaningful way to set them. 

I'm sorry, but to me your justification boils down to you saying that you don't think the users should have that kind of control over the UIs on their own machines, because … you like your UI better, and don't want to let users change it. 

Sorry, but that's not a feature. That's a bug, and apparently a deliberate one. Please reconsider.

(In reply to ExecutorElassus from comment #8)

> I'm sorry, but to me your justification boils down to you saying that you
> don't think the users should have that kind of control over the UIs on their
> own machines, because … you like your UI better, and don't want to let users
> change it. 

Remember that we didn't force you to use our UIs. If you prefer to see the exposed wiring of the traditional X desktop, you can run a standalone wm, use xrandr and xmodmap, and enjoy the feeling of being in control. I'm not saying that there is no value in that, just that we can't build a usable UI on top of it. If you can, more power to you.

[Removing advocacy comments that don't add anything technical to this task.]