Smalltalk › Squeak › Squeak - Dev

Unix keyboard events lose track when multiple keys pressed or keys held down

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

41 messages Options

123

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

> On 2021-01-17, at 10:36 AM, David T. Lewis <[hidden email]> wrote:
>
> However, when I run the VM with -compositioninput and test keystrokes using
> the 'f' and 'j' keys, this is what I see:
>
>
> [502@771 keyDown (102) 127659]
> [502@771 keystroke 'f' (102) 127659]f
> [502@771 keyDown (106) 127848]
> [502@771 keystroke 'j' (106) 127848]j
> [502@771 keyUp (106) 127969]
> [502@771 keyUp (0) 128233]
>
> It looks to me like key release event for the 'f' key is being delivered
> to the image, but it has keycode 0 instead of keycode 102.

I'll guess for now that it is a side effect of the prior mentioned XmbLookupString vs XLookupString issue.

A question we've not yet asked but that likely has some important bearing on this is just how do the composition input UI widgets and so on actually work? The only system I'm currently aware of is the relatively simple ctl-e-e to get an "é" on my iMac. I'm sure there are much more sophisticated options out there for languages using the huge range of glyphs for Chinese and Japanese etc.

I suppose in some ways it's not very relevant to the Scratch usage issue because nobody is going to want to do a complex multi-gesture action instead of one of the cursor keys as part of a twitch game! Though a twitch training game to learn the actions as part of a language teaching system...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- A .22 caliber intellect in a .357 Magnum world.

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

In reply to this post by Nicolas Cellier

> On 2021-01-17, at 1:47 AM, Nicolas Cellier <[hidden email]> wrote:
>
> IMO it's a mistake: we should always pass the keypress/release events as is to the image, that's what raw events means to be. Composition shall alter the keychar events only - that is some 1st level interpretation of the raw events...

I have much sympathy with this idea and some past experience with using it.

The good part is that you get the raw input and can do whatever you want with it; the bad part is that you get the raw input and *have* to do something with it! That can cost so much effort that you just fail to provide the user with what is needed.

In this case it would be converting the raw key code to characters with a map; but we'd have to work out how to build the map for each platform, for each variety of keyboard (Aaargh! Dvorak user approaching! Run away!) and each language. I don't think I'll live long enough to be able to implement that.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: JSP: Jump on Sexy Programmer

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

In reply to this post by David T. Lewis

> On 2021-01-17, at 8:30 AM, David T. Lewis <[hidden email]> wrote:
>
> I don't have a Pi to check, but most likely there is a unix shell
> script somewhere, such as /usr/bin/scratch, that runs the VM and brings
> up the Scratch image. If so, then you can add "unset LC_ALL" to the
> script, and I expect that Scratch will be happy again.

I suspect that some of the 'enhanced initial setup' tools that have been added may well cause the setting of the local stuff. The problem I see with unsetting LC_ALL is that it would likely break the handling of any non-english systems. Which would definitely be an issue.

Good experiment to try though.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- If his IQ was two points higher he'd be a rock.

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

> On 2021-01-17, at 11:10 AM, tim Rowledge <[hidden email]> wrote:
>
> Good experiment to try though.

It certainly allows the basic keystrokes to work and even ctl-e-e . That latter actually surprises me given the description of what XLookupString does, but life in X is always surprising - oh, wait, there's a bunch of code in case KeyPress: that handles some cases.

The log for a ctl-e-e is

(handleEvent)X KeyPress state 0x0 raw keycode 92
convert keycode 92(5c) -> 0(00) (keysym fe03 UNKNOWN CODE)
symbolic, keyCode, ucs4: fe03, -1, 0
pressed, buffer: 0, 0
multi_key reset
keyCode, ucs4, multi_key_buffer: -1, 0, 0

(handleEvent)X KeyRelease state 0x80 raw keycode 92
convert keycode 92(5c) -> 0(00) (keysym fe03 UNKNOWN CODE)
symbolic, keyCode, ucs4: fe03, -1, 0
Skip KeyRelease at keyCode/ucs4 test line 3764

(handleEvent)X KeyPress state 0x0 raw keycode 252
convert keycode [195(c3),169(a9)] 252(fc) -> 195(c3) (keysym 00e9 XK_eacute)
symbolic, keyCode, ucs4: e9, 195, e9
pressed, buffer: 0, 0
multi_key reset
keyCode, ucs4, multi_key_buffer: 195, 233, 0
signalInputEvent
EVENT (recordKeyboardEvent): time: 1565590 key down ` ' (195 = 0xc3) ucs4 233
signalInputEvent
EVENT (recordKeyboardEvent): time: 1565590 key char ` ' (195 = 0xc3) ucs4 233
(ioGetNextEvent) KEYBOARD evt: time: 1565590 press: 1 char: 195 utf32: 233
(ioGetNextEvent) KEYBOARD evt: time: 1565590 press: 0 char: 195 utf32: 233

(handleEvent)X KeyRelease state 0x0 raw keycode 252
convert keycode [195(c3),169(a9)] 252(fc) -> 195(c3) (keysym 00e9 XK_eacute)
symbolic, keyCode, ucs4: e9, 195, e9
signalInputEvent
EVENT (recordKeyboardEvent): time: 1565687 key up ` ' (195 = 0xc3) ucs4 233
(ioGetNextEvent) KEYBOARD evt: time: 1565687 press: 2 char: 195 utf32: 233

Looks like the 'multi_key_buffer' stuff is what the 'lastKey' bit was modelled on?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A computer scientist is someone who fixes things that aren't broken.

David T. Lewis

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

In reply to this post by timrowledge

On Sun, Jan 17, 2021 at 11:10:34AM -0800, tim Rowledge wrote:

>
>
> > On 2021-01-17, at 8:30 AM, David T. Lewis <[hidden email]> wrote:
> >
> > I don't have a Pi to check, but most likely there is a unix shell
> > script somewhere, such as /usr/bin/scratch, that runs the VM and brings
> > up the Scratch image. If so, then you can add "unset LC_ALL" to the
> > script, and I expect that Scratch will be happy again.
>
> I suspect that some of the 'enhanced initial setup' tools that have been
> added may well cause the setting of the local stuff.

Yes that's probably what happened. On my somewhat old Ununtu system,
LC_ALL is not set. But I can certainly see how people might decide
that the locale information should always be set to *something* and
that is probably what has been done on your newer Raspberry Pi system.

> The problem I see with unsetting LC_ALL is that it would likely break the
> handling of any non-english systems. Which would definitely be an issue.
>

If you can put it into a shell script that runs Scratch, then it
will only affect Scratch itself. Within Scratch it might be an
issue for keyboard input to Scratch. Maybe we can find a non-English
Scratch users to check that out. For Japanese Scratch users, the
LC_ALL setting should not have any effect because compositioninput
is being used.

Dave

Herbert König

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

If it's Scratch on a Raspi I can do for German.
-Where to find the script to add the LC_all?
-What to do / load?

Will be tomorrow around this time when I get to it.

Cheers,

Herbert

Am 17.01.2021 um 21:06 schrieb David T. Lewis:

> On Sun, Jan 17, 2021 at 11:10:34AM -0800, tim Rowledge wrote:
>>
>>> On 2021-01-17, at 8:30 AM, David T. Lewis <[hidden email]> wrote:
>>>
>>> I don't have a Pi to check, but most likely there is a unix shell
>>> script somewhere, such as /usr/bin/scratch, that runs the VM and brings
>>> up the Scratch image. If so, then you can add "unset LC_ALL" to the
>>> script, and I expect that Scratch will be happy again.
>> I suspect that some of the 'enhanced initial setup' tools that have been
>> added may well cause the setting of the local stuff.
> Yes that's probably what happened. On my somewhat old Ununtu system,
> LC_ALL is not set. But I can certainly see how people might decide
> that the locale information should always be set to *something* and
> that is probably what has been done on your newer Raspberry Pi system.
>
>> The problem I see with unsetting LC_ALL is that it would likely break the
>> handling of any non-english systems. Which would definitely be an issue.
>>
> If you can put it into a shell script that runs Scratch, then it
> will only affect Scratch itself. Within Scratch it might be an
> issue for keyboard input to Scratch. Maybe we can find a non-English
> Scratch users to check that out. For Japanese Scratch users, the
> LC_ALL setting should not have any effect because compositioninput
> is being used.
>
> Dave
>
>

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

> On 2021-01-17, at 1:40 PM, Herbert König <[hidden email]> wrote:
>
> If it's Scratch on a Raspi I can do for German.

Ah, excellent.

> -Where to find the script to add the LC_all?
> -What to do / load?

The easiest thing to do on a Pi is probably

sudo nano /usr/bin/scratch
just before the line "$WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS"
add
unset $LC_ALL
ctl-o
y
ctl-x

That should result in LC_ALL being undefined for the child process that actually runs scratch. I think.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Fac ut vivas. = Get a life.

David T. Lewis

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

On Sun, Jan 17, 2021 at 02:23:13PM -0800, tim Rowledge wrote:

>
>
> > On 2021-01-17, at 1:40 PM, Herbert K??nig <[hidden email]> wrote:
> >
> > If it's Scratch on a Raspi I can do for German.
>
> Ah, excellent.
>
> > -Where to find the script to add the LC_all?
> > -What to do / load?
>
> The easiest thing to do on a Pi is probably
>
> sudo nano /usr/bin/scratch
> just before the line "$WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS"
> add
> unset $LC_ALL
> ctl-o
> y
> ctl-x
>
> That should result in LC_ALL being undefined for the child process that actually runs scratch. I think.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Fac ut vivas. = Get a life.
>
>
>

Take out the dollar sign before LC_AL, so instead of this:

unset $LC_ALL

Do this:

unset LC_ALL

Tim, can you post a copy of the /usr/bin/scratch script so I can have a look at it?

Thanks,
Dave

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

> On 2021-01-17, at 3:12 PM, David T. Lewis <[hidden email]> wrote:
>
> Take out the dollar sign before LC_AL, so instead of this:
>
> unset $LC_ALL
>
> Do this:
>
> unset LC_ALL

Whoops.

>
> Tim, can you post a copy of the /usr/bin/scratch script so I can have a look at it?

Sure -

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SEOB: Set Every Other Bit

scratch (3K) Download Attachment

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

I *might* have a sensible solution that will work with LC_ALL defined.

The problem has been that in x2sqKeyInput we use XmbLookupString which cannot work with a key release. In x2sqKeyPlain we use XLookupString which *does* work with a key release.

So my suggestion is to make use of x2sqKeyPlain within the x2sqKeyInput (and probably the x2sqKeyCompositionInput too?) key release. It seems to work ok in a shell where

echo $LC_ALL
en_US.UTF-8

and the logging shows me that we are going through that route.

Attached the C file for comparison; note no change has been made to the x2sqKeyCompositionInput routine yet.

Does this seem a reasonable thing to do?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Common sense – so rare it’s a goddam superpower

sqUnixX11.c (234K) Download Attachment

Herbert König

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

In reply to this post by timrowledge

Early bird today.

With the '$' the script doesn't start, without it starts.
I'm not sure what to do but in both cases Say 'ÄÖÜßöäü' (<-- When typing
those were German Umlauts) works and displys correctly.
No sound though.
The script still uses ALSA sound.

Not sure what I shall try but can do that after work, maybe even read
the whole thread ;-).

Cheers,

Herbert

Am 17.01.21 um 23:23 schrieb tim Rowledge:

>
>> On 2021-01-17, at 1:40 PM, Herbert König <[hidden email]> wrote:
>>
>> If it's Scratch on a Raspi I can do for German.
> Ah, excellent.
>
>> -Where to find the script to add the LC_all?
>> -What to do / load?
> The easiest thing to do on a Pi is probably
>
> sudo nano /usr/bin/scratch
> just before the line "$WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS"
> add
> unset $LC_ALL
> ctl-o
> y
> ctl-x
>
> That should result in LC_ALL being undefined for the child process that actually runs scratch. I think.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Fac ut vivas. = Get a life.
>
>
>

David T. Lewis

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

In reply to this post by timrowledge

On Sun, Jan 17, 2021 at 03:58:00PM -0800, tim Rowledge wrote:

> I *might* have a sensible solution that will work with LC_ALL defined.
>
> The problem has been that in x2sqKeyInput we use XmbLookupString which cannot work with a key release. In x2sqKeyPlain we use XLookupString which *does* work with a key release.
>
> So my suggestion is to make use of x2sqKeyPlain within the x2sqKeyInput (and probably the x2sqKeyCompositionInput too?) key release. It seems to work ok in a shell where
>
> echo $LC_ALL
> en_US.UTF-8
>
> and the logging shows me that we are going through that route.
>
> Attached the C file for comparison; note no change has been made to the x2sqKeyCompositionInput routine yet.
>
>
> Does this seem a reasonable thing to do?
>

I fear that it will not work for actual multibyte input though?

Key press events would be using the multibyte XmbLookupString
routine and key release events would use single byte XLookupString.
I have no expertise in this area but it does not sound right.

Dave

David T. Lewis

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

In reply to this post by Herbert König

Hi Herbert,

Thanks for testing this Tim can give a better idea of what to test for
Scratch, but I think the basic idea is to just make sure that nothing
seems broken for keyboard text entry after making the change. If you
are able to enter German Umlouts that sounds like a good thing :-)

Also the "missing key up" problem should be resolved. Earlier in this
thread Marcel explained how to display the key events in Transcript,
and I have been following his recommendation for that.

Dave

On Mon, Jan 18, 2021 at 09:23:08AM +0100, Herbert wrote:

> Early bird today.
>
> With the '$' the script doesn't start, without it starts.
> I'm not sure what to do but in both cases Say '??????????????' (<-- When
> typing
> those were German Umlauts) works and displys correctly.
> No sound though.
> The script still uses ALSA sound.
>
> Not sure what I shall try but can do that after work, maybe even read
> the whole thread ;-).
>
> Cheers,
>
> Herbert
>
> Am 17.01.21 um 23:23 schrieb tim Rowledge:
> >
> >>On 2021-01-17, at 1:40 PM, Herbert K??nig <[hidden email]> wrote:
> >>
> >>If it's Scratch on a Raspi I can do for German.
> >Ah, excellent.
> >
> >>-Where to find the script to add the LC_all?
> >>-What to do / load?
> >The easiest thing to do on a Pi is probably
> >
> >sudo nano /usr/bin/scratch
> >just before the line "$WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT"
> >$IMOPTIONS"
> >add
> >unset $LC_ALL
> >ctl-o
> >y
> >ctl-x
> >
> >That should result in LC_ALL being undefined for the child process that
> >actually runs scratch. I think.
> >
> >tim
> >--
> >tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> >Useful Latin Phrases:- Fac ut vivas. = Get a life.
> >
> >
> >
>

David T. Lewis

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

In reply to this post by David T. Lewis

Moving to vm-dev list for follow ups on the VM. Please keep the
Scratch related part of the discussion going here on squeak-dev.

On Mon, Jan 18, 2021 at 09:29:24AM -0500, David T. Lewis wrote:

> On Sun, Jan 17, 2021 at 03:58:00PM -0800, tim Rowledge wrote:
> > I *might* have a sensible solution that will work with LC_ALL defined.
> >
> > The problem has been that in x2sqKeyInput we use XmbLookupString which cannot work with a key release. In x2sqKeyPlain we use XLookupString which *does* work with a key release.
> >
> > So my suggestion is to make use of x2sqKeyPlain within the x2sqKeyInput (and probably the x2sqKeyCompositionInput too?) key release. It seems to work ok in a shell where
> >
> > echo $LC_ALL
> > en_US.UTF-8
> >
> > and the logging shows me that we are going through that route.
> >
> > Attached the C file for comparison; note no change has been made to the x2sqKeyCompositionInput routine yet.
> >
> >
> > Does this seem a reasonable thing to do?
> >
>
> I fear that it will not work for actual multibyte input though?
>
> Key press events would be using the multibyte XmbLookupString
> routine and key release events would use single byte XLookupString.
> I have no expertise in this area but it does not sound right.
>

I think I found a clean way to handle the missing key up event problem.
I have it working in the interpreter VM now and I'll do a pull
request for opensmalltalk-vm either today or tomorrow. The commit
notice will look like this:

Fix missing KeyRelease events when multiple keys are depressed.
Reference Mantis 0007597 http://bugs.squeak.org/view.php?id=7597.
Rather than keep a single lastKey to remember the last previously pressed
pressed key value, maintain an array size 256 of last key pressed values
indexed by X11 KeyCode. Works for any number of simultaneous keys.

It will work for Japanese keyboard with composition input also.

Dave

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

> On 2021-01-18, at 10:40 AM, David T. Lewis <[hidden email]> wrote:
>
> I think I found a clean way to handle the missing key up event problem.
> I have it working in the interpreter VM now and I'll do a pull
> request for opensmalltalk-vm either today or tomorrow.

I was thinking of a similar approach at the end of last week too; if one records the ingoing charcode for a keycode then you can return it once again on a release. I got stuck trying to remember enough C to write what would be trivial in Smalltalk...

I think one of the 'interesting' problems is having a good heuristic for what happens with multiple-key cases. Say you have some input that requires ctl-e-e-opt-s or some similarly convoluted gesture. That gets you a single character input event. When do you provide the release event for that single character? Is there even a real meaning to holding down that final 'opt-s' - and what if the opt is released before the s? Do the composited characters do repeats if the opt-s is held down?

My brain will likely never fully recover from this assault.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computer Science: solving today's problems tomorrow.

Nicolas Cellier

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

Le lun. 18 janv. 2021 à 20:09, tim Rowledge <[hidden email]> a écrit :

>
>
>
> > On 2021-01-18, at 10:40 AM, David T. Lewis <[hidden email]> wrote:
> >
> > I think I found a clean way to handle the missing key up event problem.
> > I have it working in the interpreter VM now and I'll do a pull
> > request for opensmalltalk-vm either today or tomorrow.
>
> I was thinking of a similar approach at the end of last week too; if one records the ingoing charcode for a keycode then you can return it once again on a release. I got stuck trying to remember enough C to write what would be trivial in Smalltalk...
>
> I think one of the 'interesting' problems is having a good heuristic for what happens with multiple-key cases. Say you have some input that requires ctl-e-e-opt-s or some similarly convoluted gesture. That gets you a single character input event. When do you provide the release event for that single character? Is there even a real meaning to holding down that final 'opt-s' - and what if the opt is released before the s? Do the composited characters do repeats if the opt-s is held down?
>
> My brain will likely never fully recover from this assault.
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Computer Science: solving today's problems tomorrow.
>
>

My understanding is that we want to achieve a perfect order, whenever
buffered keys x & y do not compose:
KeyPress x
KeyChar x
KeyPress y
KeyChar y
KeyRelease x
KeyRelease y

rather than:
KeyPress x
KeyPress y
KeyChar x
KeyChar y
KeyRelease x
KeyRelease y

Is that it?
If we would accept second form, code would be much simpler.

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

> On 2021-01-18, at 12:08 PM, Nicolas Cellier <[hidden email]> wrote:
>
> My understanding is that we want to achieve a perfect order, whenever
> buffered keys x & y do not compose:
> KeyPress x
> KeyChar x
> KeyPress y
> KeyChar y
> KeyRelease x
> KeyRelease y
>
> rather than:
> KeyPress x
> KeyPress y
> KeyChar x
> KeyChar y
> KeyRelease x
> KeyRelease y
>
> Is that it?
> If we would accept second form, code would be much simpler.
>
>

Honestly, I don't know how to even decide if one way is more meaningful than the other for this case.

For the very narrow purposes of my work on updating/correcting NuScratch the key (hah!) is to make sure that tracking the state of the simple alphanumeric + cursor keys is accurate and timely. It will help with any sort of game/keyboard-music application too.

As soon as we consider any of the multiple-gesture characters like é or composited ones like (I imagine this delightful 'man disco dancing' from the Mongolian alphabet is) ᡲ then what to do becomes... complicated. I'd say the important thing is to make sure that at least everything is balanced so that after all the keys are pressed, held, and released, anyone using a KeyboardListener will see no keys being still down.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SG: Show Garbage

David T. Lewis

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

In reply to this post by David T. Lewis

On Mon, Jan 18, 2021 at 01:40:11PM -0500, David T. Lewis wrote:

> Moving to vm-dev list for follow ups on the VM. Please keep the
> Scratch related part of the discussion going here on squeak-dev.
>
> On Mon, Jan 18, 2021 at 09:29:24AM -0500, David T. Lewis wrote:
> > On Sun, Jan 17, 2021 at 03:58:00PM -0800, tim Rowledge wrote:
> > > I *might* have a sensible solution that will work with LC_ALL defined.
> > >
> > > The problem has been that in x2sqKeyInput we use XmbLookupString which cannot work with a key release. In x2sqKeyPlain we use XLookupString which *does* work with a key release.
> > >
> > > So my suggestion is to make use of x2sqKeyPlain within the x2sqKeyInput (and probably the x2sqKeyCompositionInput too?) key release. It seems to work ok in a shell where
> > >
> > > echo $LC_ALL
> > > en_US.UTF-8
> > >
> > > and the logging shows me that we are going through that route.
> > >
> > > Attached the C file for comparison; note no change has been made to the x2sqKeyCompositionInput routine yet.
> > >
> > >
> > > Does this seem a reasonable thing to do?
> > >
> >
> > I fear that it will not work for actual multibyte input though?
> >
> > Key press events would be using the multibyte XmbLookupString
> > routine and key release events would use single byte XLookupString.
> > I have no expertise in this area but it does not sound right.
> >
>
> I think I found a clean way to handle the missing key up event problem.
> I have it working in the interpreter VM now and I'll do a pull
> request for opensmalltalk-vm either today or tomorrow. The commit
> notice will look like this:
>
> Fix missing KeyRelease events when multiple keys are depressed.
> Reference Mantis 0007597 http://bugs.squeak.org/view.php?id=7597.
> Rather than keep a single lastKey to remember the last previously pressed
> pressed key value, maintain an array size 256 of last key pressed values
> indexed by X11 KeyCode. Works for any number of simultaneous keys.
>
> It will work for Japanese keyboard with composition input also.
>
> Dave
>

Pull request for the fix is https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/547

I also pushed an update to SVN on squeakvm.org for interpreter VM.

Dave

timrowledge

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

Looks sensible to me; the only question I have is whether it is actually guaranteed that no keycode can exceed 255? All I can find out right now is that the structure definition has it as an int.

>
> Pull request for the fix is https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/547
>
> I also pushed an update to SVN on squeakvm.org for interpreter VM.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Hipatitis (n): Terminal coolness

Nicolas Cellier

Re: Unix keyboard events lose track when multiple keys pressed or keys held down

I would think we can do much simpler if we abandon the idea of ordering events.
Deliver the raw event (Pess and release) ASAP.
All we need is a translation of raw scan code to a platform independent keycode.
For the cooked event (EventKeyChar), just do not change anything.
What do you think?

Le mar. 19 janv. 2021 à 00:10, tim Rowledge <[hidden email]> a écrit :

>
> Looks sensible to me; the only question I have is whether it is actually guaranteed that no keycode can exceed 255? All I can find out right now is that the structure definition has it as an int.
>
> >
> > Pull request for the fix is https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/547
> >
> > I also pushed an update to SVN on squeakvm.org for interpreter VM.
>
>
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Hipatitis (n): Terminal coolness
>
>
>

123