grave accent key not working on Mac with US international layout

[mat007]

Ebitengine Version

3eaa03e

Operating System

• Windows
• macOS
• Linux
• FreeBSD
• OpenBSD
• Android
• iOS
• Nintendo Switch
• PlayStation 5
• Xbox
• Web Browsers

Go Version (go version)

go version go1.22.0 darwin/amd64

What steps will reproduce the problem?

go run ./examples/keyboard/

then hit the key above tab and left of 1.

What is the expected result?

The key to be displayed in the top left corner, perhaps something like Backquote, @ (I'm using a French layout, I tested Dvorak as well).

What happens instead?

Nothing

Anything else you feel useful to add?

I've looked as best as I could at the code, from as far as I can tell it seems it's all wired up correctly, with Backquote mapped to the GLFW GraveAccent key code (96).

[hajimehoshi]

https://pkg.go.dev/github.com/hajimehoshi/ebiten/v2#IsKeyPressed

Note that a Key represents a physical key of US keyboard layout. For example, KeyQ represents Q key on US keyboards and ' (quote) key on Dvorak keyboards.

So the French layout might be different from the US.

[hajimehoshi]

I close this as this is WAI

[mat007]

Hey, thanks for your answer. I don't think the layout is really the culprit here.
I just tested with a US ABC layout, and the key does not work either.

[mat007]

Or with a U.S., it doesn't work either.

[hajimehoshi]

What kind of keyboard are you using?

[mat007]

Do you mean the hardware? It’s the integrated keyboard with the laptop.

[hajimehoshi]

Backquote, @

OK this is expected: Backquote indicates the US key by IsKeyPressed, while @ indicates the result of KeyName, which reflects the current keyboard layout. With my AZERTY keyboard on my MacBook Pro M3, Backquote and < was shown. So the backquote character [*] doesn't have to be shown, but I am not sure why the result doesn't match. Also, I am not sure why your US keyboard returns a different result. With your US keyboard layout, Backquote and a different key name was shown, right?

[*] I cannot wirte a single backquote character in a GitHub comment lol

[mat007]

It does work on Windows

but whatever keyboard layout I choose on Mac I cannot manage to have the Backquote showing up…

[hajimehoshi]

but whatever keyboard layout I choose on Mac I cannot manage to have the Backquote showing up…

Ah sorry, I was a little misunderstanding: you said Backquote itself was not shown.

[hajimehoshi]

What is your hardware keyboard's layout? (I'm using a US layout hardware keyboard)

[mat007]

you said Backquote itself was not shown.

Yes, sorry, I realize I could have been a bit clearer 😅

With my AZERTY keyboard on my MacBook Pro M3, Backquote and < was shown.

Hmm, I'm testing on a 2016 Mac Book Pro Intel with Monterey 12.6.9 at the moment. Maybe I should update the system…
I have an M1 as well that's more up-to-date, which is my work laptop that I don't usually use for personal stuff, but I'll see if I can quickly test on it.

[mat007]

What is your hardware keyboard's layout? (I'm using a US layout hardware keyboard)

You mean the labels printed on the keys? It's a French layout (azerty).

The character that shows up when I type with the US layout, e.g. in a GitHub comment, is § which is different than your < 🤔

[mat007]

Ah, so apparently there are ANSI and ISO keyboards.
This is likely why we're seeing discrepancies you and me?

[mat007]

Right, so it seems my machine may be misconfigured somehow, possibly? 😅
https://apple.stackexchange.com/questions/304819/british-mac-keyboard-and-key-the-wrong-way-around

[hajimehoshi]

Possibly yes. But you have tested a GLFW app and it worked as you intended, right?

Also, what would the result be in your environment? https://www.toptal.com/developers/keycode

[mat007]

But you have tested a GLFW app and it worked as you intended, right?

Ah no sorry, I have no clue how to do that 😬

Also, what would the result be in your environment? https://www.toptal.com/developers/keycode

With a US keyboard selected it's

{
 "key": "§",
 "keyCode": 192,
 "which": 192,
 "code": "Backquote",
 "location": 0,
 "altKey": false,
 "ctrlKey": false,
 "metaKey": false,
 "shiftKey": false,
 "repeat": false
}

with a different layout, it's different, e.g. the French layout has

{
 "key": "@",
 "keyCode": 64,
 "which": 64,
 "code": "Backquote",
 "location": 0,
 "altKey": false,
 "ctrlKey": false,
 "metaKey": false,
 "shiftKey": false,
 "repeat": false
}

The code is always Backquote though…

[hajimehoshi]

OK so your browser does a hack (?) to treat your backquote key. Hmm...

[mat007]

So, possibly interestingly, my M1 has a qwerty Keyboard.

Is that the same layout as your M3?

When I use the English US layout, and I press the key left of Z, then the keyboard ebiten example shows me «Backquote ~». The key left of 1 does not do anything.

But using https://www.toptal.com/developers/keycode, For the key left of Z I get

{
 "key": "`",
 "keyCode": 192,
 "which": 192,
 "code": "IntlBackslash",
 "location": 0,
 "altKey": false,
 "ctrlKey": false,
 "metaKey": false,
 "shiftKey": false,
 "repeat": true
}

(IntlBackslash??)
and for the key left of 1

{
 "key": "§",
 "keyCode": 192,
 "which": 192,
 "code": "Backquote",
 "location": 0,
 "altKey": false,
 "ctrlKey": false,
 "metaKey": false,
 "shiftKey": false,
 "repeat": true
}

So perhaps it’s me who was assuming the key left of 1 was supposed to be Backquote, when it never was?
Or maybe I’m simply confused because the last time I did something like that was years ago using https://github.com/wgois/OIS which probably is scancode based, now that I think of it? 🤔

But then is there no way to capture that key press?

[hajimehoshi]

Is that the same layout as your M3?

No, mine is QWERTY but the left key of 1 is tilde and backquote. Also the left key of z is a shift in mine. I guess yours is UK US international layout [1], while mine is US layout.

[1] https://keyshorts.com/blogs/blog/37615873-how-to-identify-macbook-keyboard-localization#us-international

[hajimehoshi]

microsoft/vscode#24153 might be related

[hajimehoshi]

https://chromium-review.googlesource.com/c/chromium/src/+/4923631

[hajimehoshi]

I'm still not sure what's going on, but exposing GLFW_KEY_WORLD1 and GLFW_KEY_WORLD2 would mitigate your issue. I'll take a look later.

[hajimehoshi]

From https://issues.chromium.org/issues/40821908#comment18, the ISO layout doesn't define what top-left physical key represents. This might be § or backquote or otherwise. Even though your top-left key is printed as §, this is Apple specific. The top-left corner key should always be IntlBackslash. I'll add ebiten.KeyIntlBackslash later.

The left key of the left shift in your keyboard should represent backquote, so with examples/keyboard, pressing that key should show "Backquote". Is that correct?

(from https://developer.apple.com/library/archive/documentation/mac/pdf/MacintoshToolboxEssentials.pdf)

[hajimehoshi]

I've added KeyIntlBackslash. Please try

go run github.com/hajimehoshi/ebiten/v2/examples/keyboard@7389f9ddb22e6839fb21e0de37eeb50dce8213ce

[mat007]

The left key of the left shift in your keyboard should represent backquote, so with examples/keyboard, pressing that key should show "Backquote". Is that correct?

I assume you meant right of left shift, but yes, correct, on both my laptops.

I've added KeyIntlBackslash. Please try (…)

Thanks!
Yes, it does correctly identify the key left of 1 as IntlBackslash on both my laptops.
For reference my Intel machine has a French layout, with both IntlBackslash and Backquote keys.

So now, I’m wondering how I should handle things to cover all keyboards.
If my game gets a IntlBackslash, obviously it’s the top left key. But if it gets a Backquote, there is no way I can tell if it’s the top left key or the bottom left one, is there?

[hajimehoshi]

I assume you meant right of left shift, but yes, correct, on both my laptops.

Yeah, you are right. I meant the right key of the left shift. Thank you for confirming!

If my game gets a IntlBackslash, obviously it’s the top left key. But if it gets a Backquote, there is no way I can tell if it’s the top left key or the bottom left one, is there?

Unfortunately no. There is no stable way to get the state of a top-left pyhisical keyboard key in any layouts. I don't think this is a solvable issue... https://www.w3.org/TR/uievents-code/#keyboard-layout explains how chaotic keyboards are.

[mat007]

With https://www.toptal.com/developers/keycode showing the IntBacklash for the key left of Z and the Backquote for the one left of 1, does it mean there is a swap somewhere happening, compared to ebiten?
(my browser is Firefox in case it matters).

[mat007]

Ah it says «The physical key on the keyboard.» for event.code so it must be trying to map it to a physical layout, somehow.
I guess it’s quite complicated to do, and probably falls out of scope of this issue? 😄

[hajimehoshi]

With https://www.toptal.com/developers/keycode showing the IntBacklash for the key left of Z and the Backquote for the one left of 1, does it mean there is a swap somewhere happening, compared to ebiten?

Ebitengine tries to follow Chrome's behaviors. Firefox might be different. Also, these keys depend on Apple or Windows (see https://issues.chromium.org/issues/40821908#comment18).

Ah it says «The physical key on the keyboard.» for event.code so it must be trying to map it to a physical layout, somehow.
I guess it’s quite complicated to do, and probably falls out of scope of this issue? 😄

Right. Browsers (and Ebitengine) try to do the best, but there is no perfect solution.

As ebiten.KeyIntlBackslash should mitigate your issue to some extent, and there is no further action item, let me close this issue. Thank you for reporting!

[mat007]

Ebitengine tries to follow Chrome's behaviors. Firefox might be different.

Oh indeed! With Chrome I see IntlBackslash on the upper left key and Backquote on the lower left one, so the opposite of Firefox. 🤔

Thanks for your prompt investigation and action!