On Tue, Jan 12, 2021 at 09:43:45PM -0800, tim Rowledge wrote:
> One of the things I had to make for NuScratch was a keyboardlistener that keeps a bitmap of the keys currently pressed - quite a few Scratch things are state dependent rather than even responsive. It originally worked pretty well as far as anybody could ever see; I had no reports of problems for years.
> 
> Whilst trying to make a 5.3 version it seems that something is making it much less reliable. It is clear from some tracking code that if one holds down a key, presses and releases another key and then finally releases the initial key, that we are losing the  final expected  key-up of the held-down key. Which in turn leaves my keyboard listener thinking the key is still pressed. This is a Bad Thing. It causes me to lose games of Asteroid Blaster. I don't like to lose at Asteroid Blaster.
> 
> Looking at the unix VM keystroke handling code causes migraines. Has anybody got any idea what on earth is going on down there? I'll build a VM with the relevant debug code turned on soon but really... if anyone that knows this part could save some pain it would be very pleasant.
>

Your question reminded me of something from a previous round of
debugging a similar (same?) issue circa 2011 (see Mantis 0007597).

There is a standard X11 utility program called xev that displays
X events as they are being generated, and another program called
xwininfo that lets you identify X11 windows and their parent and
children and such. I'm going to predict that the man pages are
likely to drive you crazy, but if you read them patiently a few
dozen times, it's all in there.

The output of xev is overwhelming, but you can redirect it to a
file and look through that if you're patient.

Another thing that is not too obvious is that the X11 window for
the Squeak display is actually one window directly embedded in
another of the same dimensions, so it can be a bit tricky to figure
out which window is the "real" one.

Your Squeak VM is an X11 client program that opens X11 windows
under the control of the X window server. The events that you
see are looking at with the xev program are the raw events, some
of which are delivered to your client program (the VM) when the
Squeak window is active and you are typing on your keyboard.
The client VM program recieves the events and converts them into
into Squeak events, and those events get delivered to the image.

You can think of the X11 events from the X server as analogous
to the Windows events on MS-Windows, in both cases the system
(X server or Windows OS) has a source of events, some of which
are delivered to your VM, and in both cases the raw events get
converted in the VM into the Squeak event format for delivery
to the image.

In order to debug this mess, the first order of business would
be to confirm that the ncessary keyup events actually are happening
over in X11. So if you were using xev to write all of the events
to a file, and if you carefully and quickly press the exact sequence
of keystrokes of interest, then you would be looking for evidence
of the "missing" keyup event appearing somewhere in the xev output.

On the image side, you would want to confirm that the keyup event
is actually missing (as opposed to being somehow misused in the
image code). I think there are some morphs to help with this, and
Matthew Fulmer's change set attached to the Mantis issue might
help if you can get it to work in modern Squeak (the change set
is an attachment on http://bugs.squeak.org/view.php?id=7597.

If the events are present in X11 but missing by the time they
get delivered to the image, then it's got to be a problem in
the VM, most likely in the vm-display-X11 module.

Dave