GNOME Bugzilla – Bug 67066
GDK_LOCK_MASK vs X Lock modifier
Last modified: 2011-02-04 16:11:52 UTC
GdkModifierType has GDK_LOCK_MASK as the X Lock modifier. Code in gdk/x11/gdkkeys-x11.c interprets it as Shift Lock: if ((state & GDK_SHIFT_MASK) && (state & GDK_LOCK_MASK)) shift_level = 0; /* shift disables shift lock */ else if ((state & GDK_SHIFT_MASK) || (state & GDK_LOCK_MASK)) shift_level = 1; else shift_level = 0; while section L6.6 of the ICCCM states that "the Lock modifier should be interpreted as Caps Lock or Shift Lock according as the keycodes in its controlling set inlude XK_Caps_Lock or XK_Shift_Lock." Beware that I don't really have an idea what the difference between Shift and Caps Lock is, so maybe I'm off base here...
Chapter 12.7 of the Xlib manual explains the difference - Shift Lock acts as a locked down shift key, while Caps Lock shifts only alphanumeric characters. Indeeded, this looks like it is doing Shift Lock, which is most likely wrong for almost any user; Caps Lock is the normal behavior. So, yes, there is a bug here; if it was simply that we always used the Caps Lock interpretation, I'd probably say that was OK, since this is only fallback code for systems without XKB and with XKB, this is all handled within XKB. But as it's always the Shift Lock interpretation. it probably should be fixed. (I think you basically have to do XConvertCase on the keysym and see if it makes a difference to figure out whether Caps Lock applies or not.)
Putting on 2.0.1, since this problem only occurs for non-Xkb, which is relatively uncommon these days.
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Patch in bug 93575
Committed a fix. Not quite as much testing as I'd like for a complex patch. Wed Oct 16 18:25:24 2002 Owen Taylor <otaylor@redhat.com> * gdk/x11/gdkkeys-x11.c: Rewrite the handling of key translation for the non-XKB case to properly handle Shift_Lock, Caps_Lock, Num_Lock according to the Xlib spec. (#67066)