1# HG changeset patch2# User Sören Tempel <soeren+hg@soeren-tempel.net>3# Date 1608985828 -36004# Sat Dec 26 13:30:28 2020 +01005# Node ID 30a5839182285fa252fc7d9268c5df5b5cc07eb66# Parent 8fd69c7dfe881e87efaf1c14c33653ad61488ec87gui-x11: Don't use X11 standard interpretation for modifiers89Using XLookupString to determine the KeySym causes the KeySym to be10interpreted according to the “standard interpretation of the Shift,11Lock, group, and numlock modifiers as defined in the X Protocol12specification.” (see XLookupKeysym(3)). For example, pressing shift and13'a' causes 'A' to be returned as a KeySym.1415When considering modifier keys this behaviour is undesirable. For16instance, X11 xkb definitions which use the both_capslock rule (e.g.17`setxkbmap de neo`) emit Shift_L with XLookupString when Shift_L/Shift_R18is pressed but emit Caps_Lock on release as Shift_L acts as a modifier19in this case (check with xev(1)). This causes Plan 9 to think that the20Shift key is constantly pressed (as a key release event for Shift is21never emitted by drawterm) thereby causing the context menu in rio to22not work correctly. As a side note, capitalization is not effected by23this as letters are capitalized by drawterm, not Plan 9.2425If my understanding of X11 is correct, using XLookupString on modifier26keys is a bad idea in this particular code, instead XLookupKeysym should27be used for modifiers.2829diff -r 8fd69c7dfe88 -r 30a583918228 gui-x11/x11.c30--- a/gui-x11/x11.c Wed Dec 23 15:58:36 2020 +010031+++ b/gui-x11/x11.c Sat Dec 26 13:30:28 2020 +010032@@ -791,6 +791,10 @@3334 if(k == XK_Multi_key || k == NoSymbol)35 return;36+ /* dont use standard interpretation for modifiers */37+ if(IsModifierKey(k))38+ k = XLookupKeysym((XKeyEvent*)e, 0);39+40 if(k&0xFF00){41 switch(k){42 case XK_BackSpace: