Re: [9front] [PATCH] Fix shift release events in X11 drawterm with shift:both_capslock xmodmap option

[hiro <23hiro@gmail.com>]

what exactly are you receiving from x11 when you "enable" your
double-shift-caps-lock?

1. shiftdown_left 2. shiftdown_right 3. capslockdown 4. shiftup_left
5. shiftup_right 6. capslocksup ?
which of these are visible, or are they in a different order? e.g. i
can easily imagine something like 123645

On Sat, Jun 29, 2024 at 1:53 AM Timothy Robert Bednarzyk <mail@trbsw.dev> wrote:
>
> I have recently started using 9front on a couple of different machines
> (including a native installation on my Thinkpad T470) and use drawterm
> on my main laptop (which uses the X11 window manager dwm on Artix Linux)
> to connect to one of them. However, on that laptop, I have the caps lock
> key remapped to be another control key (ctrl:no_caps) and I have it set
> to toggle caps lock when I press both shift keys at the same time
> (shift:both_capslock). As it turns out, when the latter xmodmap option
> is set, XLookupString interprets shift key release events as caps lock
> key release events. This was causing my middle and right mouse buttons
> to effectively be swapped permanently after pressing a shift key even
> once in a drawterm session (although I didn't know why it was happening
> until I did some research and found someone else mentioning them having
> shift-related problems in a different program whenever they were using
> shift:both_capslock).
>
> I ended up solving this by utilizing the rather strange and unintuitive
> fact that the xkey event's state still has the ShiftMask bit set during
> the release event (even for actual shift key release events, according
> to what I found during my research) and using that to determine whether
> the release event should be interpreted as being for a shift key or for
> the caps lock key. This likely will cause the middle and right mouse
> buttons to unswap if the user is holding down the shift key while
> releasing the caps lock key, but considering how unlikely of a scenario
> that is and the fact that it is only a temporary and mild problem (all
> they would have to do is release and re-press the shift key), I think
> this fix is acceptable enough (unless someone else can think of a better
> solution, which I would greatly appreciate).
>
> diff --git a/gui-x11/x11.c b/gui-x11/x11.c
> index b4f1ad3..8f2b694 100644
> --- a/gui-x11/x11.c
> +++ b/gui-x11/x11.c
> @@ -882,7 +882,16 @@ xkeyboard(XEvent *e)
>                         break;
>                 case XK_Shift_Lock:
>                 case XK_Caps_Lock:
> -                       k = Kcaps;
> +                       /*
> +                        * Using the xmodmap option shift:both_capslock causes shift
> +                        * release events to appear as capslock release events instead.
> +                        * Not having this causes the middle and right mouse buttons to
> +                        * be swapped permanently after the shift key is pressed once.
> +                        */
> +                       if(e->xany.type == KeyRelease && (e->xkey.state & ShiftMask))
> +                               k = Kshift;
> +                       else
> +                               k = Kcaps;
>                         break;
>                 case XK_Scroll_Lock:
>                         k = Kscroll;
>
> --
> trb