[squeak-dev] Unix keyboard events lose track when multiple keys pressed or keys held down

Marcel Taeumel marcel.taeumel at hpi.de
Fri Jan 15 08:40:06 UTC 2021


Hi Dave.

> Next debugging step would be to confirm whether or not the "y" release
> event is being delivered to the image.

1) Add a "Transcript showln: anEvent" to the beginning of HandMorph >> #showEvent:.
2) Do it: "HandMorph showEvents: true"
3) Open a transcript window and observe.

Best,
Marcel
Am 14.01.2021 22:10:01 schrieb David T. Lewis <lewis at mail.msen.com>:
On Wed, Jan 13, 2021 at 08:51:03PM -0500, David T. Lewis wrote:
> 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.
>

I used xev to check out the X11 events that get generated from the
keyboard. My test was to do this (quickly)with xev running:

- depress "x" key
- depreas "y" key
- release "y" key
- release "x" key

The X11 events as logged by xev were:


KeyPress event, serial 37, synthetic NO, window 0x4a00001,
root 0x157, subw 0x0, time 47948369, (-236,-191), root:(1506,711),
state 0x0, keycode 53 (keysym 0x78, x), same_screen YES,
XLookupString gives 1 bytes: (78) "x"
XmbLookupString gives 1 bytes: (78) "x"
XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x4a00001,
root 0x157, subw 0x0, time 47948766, (-236,-191), root:(1506,711),
state 0x0, keycode 29 (keysym 0x79, y), same_screen YES,
XLookupString gives 1 bytes: (79) "y"
XmbLookupString gives 1 bytes: (79) "y"
XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x4a00001,
root 0x157, subw 0x0, time 47949114, (-236,-191), root:(1506,711),
state 0x0, keycode 29 (keysym 0x79, y), same_screen YES,
XLookupString gives 1 bytes: (79) "y"
XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x4a00001,
root 0x157, subw 0x0, time 47949541, (-236,-191), root:(1506,711),
state 0x0, keycode 53 (keysym 0x78, x), same_screen YES,
XLookupString gives 1 bytes: (78) "x"
XFilterEvent returns: False

Conclusion: All of the necessary keyboard events are generated by the
X server and we can safely assume that they are being delivered to
the VM.

Next debugging step would be to confirm whether or not the "y" release
event is being delivered to the image.

Dave


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210115/d0035db2/attachment.html>


More information about the Squeak-dev mailing list