Strange Caps Lock behaviour in Hatari 2.3!

[distantminds]

Hello there,

I've just stumbled upon what appears to be a strange bug with Hatari 2.3 on OS X. Caps Lock only seems to register on the emulated atari every other key press! So to toggle between upper and lower case takes two presses rather than one!

I tried an external PC ISO keyboard as well and I see the same behaviour.

The only earlier version I have - One of Troed's nightly's of Hatari 2.2, works as one would expect.

I tried the official releases of 2.3, and I also built a version myself.

Many thanks for your interest,
Damo

[Eero Tamminen]

Do these versions bundle different Mac SDL version? If yes, but it's still SDL v2, could you try whether using the SDL2 version from Hatari v2.3 with v2.2 causes the issue?

[darwinmac]

Hello there,

I've just stumbled upon what appears to be a strange bug with Hatari 2.3 on OS X. Caps Lock only seems to register on the emulated atari every other key press! So to toggle between upper and lower case takes two presses rather than one!

I tried an external PC ISO keyboard as well and I see the same behaviour.

The only earlier version I have - One of Troed's nightly's of Hatari 2.2, works as one would expect.

I tried the official releases of 2.3, and I also built a version myself.

Many thanks for your interest,
Damo

I am running Hatari 2.3.1 on macOS Big Sur (macOS 11). I am also running the latest SDL version (2.0.14). I did not normally see your behavior on my M1 MacBook Air. However, both in macOS and Hatari, I did see some times where the caps lock key did not engage unless I made sure to press it firmly. It looked like Apple may not want the caps lock key to be too easily engaged. However, whenever I made sure to press the caps lock key firmly, Hatari recognized the caps lock immediately. It did not take a second keypress in order for the caps lock to be in effect. I used Word Writer ST to test the caps lock. I tried turning it on and off at least 15-20 times.

I saw the same behavior where the caps lock key did not register outside of Hatari (in TextEdit). As I previously said, if I firmly pressed the caps lock key, it always worked in Hatari and macOS. If I quickly pressed the key, it may or may not have registered the caps lock keypress.

Bob C

[distantminds]

Hello both,

many thanks for your replies.

Bob - I know what you mean about my Macbook Keyboard Caps Lock and sure, i've seen that behaviour before on previous versions. But this is a definitive two clicks on, two clicks off scenario And I do see the same thing with a PC keyboard plugged in also, very odd.

Eero - i'm not sure whether they use different (point) versions of SDL - i'll try my best to examine that area thank you.

Cheers both of you,

D

[Eero Tamminen]

How does the "--trace keymap" output differ between your two Hatari versions, when you press Caps Lock?

[distantminds]

Hi Eero,

In one of Troed's nightly 2.2 builds where the Caps Lock behaviour works as i'd expect, --trace keymap behaves as such:

Pressing down Caps Lock (or any other key for that matter)

Code: Select all

key down: sym=1073741881 scan=57 mod=0x2000 name='CapsLock'
key map: sym=0x40000039 to ST-scan=0x3a

and upon release:

Code: Select all

key up: sym=1073741881 scan=57 mod=0x2000 name='CapsLock'

Whereas, the official 2.3 build (and my own local build) behave slightly differently. All other keys behave as above, but Caps Lock is as such:

On press:

Code: Select all

key down: sym=1073741881 scan=57 mod=0x2000 name='CapsLock'
key map: sym=0x40000039 to ST-scan=0x3a

On depress:

nothing.

Then, on second press:

Code: Select all

key up: sym=1073741881 scan=57 mod=0x2000 name='CapsLock'

and on depress:

nothing.

Strange one

[Eero Tamminen]

That is indeed odd.

There have been only couple of small changes to Hatari "keymap.c" file between v2.2 and v2.3, and I don't see how any of them could have caused something like that.

I still think this is more likely to be a libSDL2 Mac backend issue, or issue with the newer XCode / Mac frameworks with which I think Hatari v2.3 binaries to be compiled with. After backing up the files, try older Hatari release with libs from newer one, and vice verse. If there's change in behavior, try changing the libs one at the time until you find the culprit.

[distantminds]

Thanks Eero.

[Eero Tamminen]

Thanks Eero.

If you found one of the libs to be issue, please report it here!

[distantminds]

If you found one of the libs to be issue, please report it here!

Nothing to report - I"m afraid I don't have the skills to identify whether an SDL library version is at fault here. For me now, i'm just avoiding pressing Caps Lock/using Caps Lock in my application!

Cheers,
D

[Eero Tamminen]

Well it doesn't require any special skills. Just take copy of working & broken versions and then replace the library files in the broken version with ones from the working version one-by-one (or vice verse), and test Hatari after each change until you find library causing issue (some combos may not work, then just move to next library).

[distantminds]

OK.

It seems to be newer build of SDL2 (28th November 2020) that ships with 2.3 causing the issue. If I replace the whole Framework with the one from Troed's 2.2 build (SDL2 build date 15th March 2020) then lo and behold - it works!

I tried to swap individual Header files only to try and narrow down the area of interest - specifically SDL_keyboard.h and SDL_keycode.h. This *almost* works - you get an affirmed Caps Lock press every time, but there's some buggy debounce going on which is not surprising given the way i'm messing around with it.

Well, I guess I have a fix Thanks Eero

[Eero Tamminen]

Have you reported this to Troed? He may have missed this thread...

[distantminds]

No - Troed's build is the one with the working SDL framework. The 'official' build of 2.31 contains the problematic SDL version for me.

[darwinmac]

No - Troed's build is the one with the working SDL framework. The 'official' build of 2.31 contains the problematic SDL version for me.

Troed also builds for 2.3.1 as well. I know he updated the SDL framework to allow for a Universal binary. That allows those of us with M1 Macs to be able to use our game pads/joysticks in Hatari.

However, that newer framework could also be what’s causing your CapsLock problem.

Bob C

[distantminds]

ok good to know thanks Bob. Hope you're enjoying the Hatari experience on your M1

[troed]

Hi all,

I've been pointed to this thread and will take a look at it when I find some time. In the meantime, please check if a later build solves the problem. My build system produces new builds whenever there's new code checked in. They can be found here: https://troed.ddns.net/d/b90229b625/

/Troed

[distantminds]

Hiya Troed nice to see you.

There might have been a mis-communication - the problem is not specific by any means to your builds - in fact I was able to 'fix' the official Hatari 2.31 build by swapping the SDL2 framework from your 2.2 build..

It seems like it's a compatibility issue between Hatari and a particular SDL2 framework - I'm not sure how the Hatari team will look to resolve that.

Cheers, and many thanks for your builds!

D

[distantminds]

Hi again

Your latest nightly build works absolutely fine also

[troed]

Your latest nightly build works absolutely fine also

Well the v2.3.1 build is also done by me so they're all "mine" But there might've been different SDL versions in them causing this. Since the latest devbuild is working fine I'll look at whether I should replace SDL in v2.3.1 or just let it be as it is.

Thanks for conforming the latest builds works.

regards,
Troed

[distantminds]

ahh I see!

a double thanks is in order then!