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

[Jacob Moody <moody@posixcafe.org>]

On 6/28/24 18:53, Timothy Robert Bednarzyk 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).

Seems reasonable to me. Thanks for debugging this.
My only suggestion would be to axe the "Not having this causes the mouse ...".
What it causes is the shift key to be held down, which then causes the mouse button swapping.
Drawterm itself isn't doing that bit, it's rio.

Thanks,
moody