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

David T. Lewis lewis at mail.msen.com
Fri Jan 15 22:20:29 UTC 2021


On Fri, Jan 15, 2021 at 09:40:06AM +0100, Marcel Taeumel wrote:
> 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.
> 

Thanks Marcel,

Thanks, that works really well. And the results are interesting.

On a Spur VM, I cannot reproduce the problem. Here is what I saw:

[452 at 596 keyDown (102) 85961993]
[452 at 596 keystroke 'f' (102) 85961993]f
[452 at 596 keyDown (106) 85962215]
[452 at 596 keystroke 'j' (106) 85962215]j
[452 at 596 keyUp (106) 85962285]
[452 at 596 keyUp (102) 85962664]

The test was press "f", press "j", release "j", release "f"

Then I repeated the test on an interpreter VM, and it *does" have the
problem. Presumably this is the issue that was reported on Mantis 0007597.
According to the Mantis report, the issue was fixed in Cog (and presumably
not in the interpreter VM).

Tim, can you try this on your Raspberry Pi and see if you can reproduce?

Here is the Spur VM that I used:

Virtual Machine
---------------
/usr/local/lib/squeak/5.0-202007252116/squeak
Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2780]
Unix built on Jul 25 2020 21:21:30 Compiler: 4.2.1 Compatible Clang 7.0.0 (tags/RELEASE_700/final)
platform sources revision VM: 202007252116 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jul 25 14:16:21 2020 CommitHash: c53070d Plugins: 202007252116 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
CoInterpreter VMMaker.oscog-eem.2780 uuid: 5e381464-117c-4633-8fe7-a95973208436 Jul 25 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2780 uuid: 5e381464-117c-4633-8fe7-a95973208436 Jul 25 2020

Dave


> 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
> 
> 

> 



More information about the Squeak-dev mailing list