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

[hiro <23hiro@gmail.com>]

this does seem like your xmodmap is causing a bug in x11.
the behavior is completely non-sensical. maybe nobody ever tested this
x11 feature? ;)
not sure how much we should care about workarounds for bugs that only
happen in an edge-case of a (mis-?)configuration.
otoh a few well commented lines that contain a good justification for
this braindamage, which now exists after such deep analysis wouldn't
bother me personally... even if it's just a link to this thread.

On Sat, Jun 29, 2024 at 7:19 PM Timothy Robert Bednarzyk <mail@trbsw.dev> wrote:
>
> > 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
>
> Below, to the left of each colon represents what I am physically doing
> and to the right represents the events that occur in X11. On the left, I
> will use PL/PR for me pressing the left/right shift keys and RL/RR for
> releasing the left/right shift keys. On the right, I will use your
> numbers.
>
> PL, RL: 1, 6.
>
> PR, RR: 2, 6.
>
> PL, PR, RL, RR: 1, 3, 6, 5.
>
> PL, PR, RR, RL: 1, 3, 6, 6.
>
> PR, PL, RL, RR: 2, 3, 6, 6.
>
> PR, PL, RR, RL: 2, 3, 6, 4.
>
> Interestingly, if I press one shift key, then the other, release the
> first shift key, and then release the second one, I do actually get the
> release event for the second shift key. I also don't get a press event
> for that second shift key, but that makes sense to me since pressing the
> second shift key is supposed to be interpreted as pressing caps lock
> anyways. Perhaps most interesting to me though is that if I instead
> release the second shift key before the first one I get two events for
> releasing the caps lock in a row and zero events for releasing shift
> keys.
>
> While the press/release events work strangely with xmodmap's
> shift:both_capslock option, the modifier masks do behave normally and I
> believe that is why I have never noticed a problem in any other program
> in the ~2/3 of a year that I've been using it (and why I wasn't stuck
> typing in all caps through drawterm despite the mouse buttons staying
> swapped). Perhaps a more robust solution to the problem would be to
> probe the current state of the modifiers when handling things such as
> mouse button presses rather than to rely on press/release events, but I
> don't know nearly enough to know how difficult or feasible doing that
> would be.
>
> --
> trb