search

Neotron-Compute / Neotron-Desktop-BIOS

A Neotron BIOS that runs as a Linux/macOS/Windows GUI application
GNU General Public License v3.0
3 stars 1 forks source link

Azerty keyboard swaps A and Q and so on, many others return X or nothing #14

Open CHiPs44 opened 11 months ago

CHiPs44 commented 11 months ago

In src/lib.rs, I changed pc_keyboard::layouts::AnyLayout::Uk105Key(pc_keyboard::layouts::Uk105Key), to pc_keyboard::layouts::AnyLayout::Azerty(pc_keyboard::layouts::Azerty) for a french AZERTY keyboard.

The result is that A gives a Q, Z a W: it seems letters swapped between QWERTY and AZERTY on the physical keyboard are swapped twice.

For <, >, $ and others, result is X or x depending on Shift state.

Numeric line seems to work fine, 2 gives an é, which is correct.

² key at top left returns nothing.

I don't know if the problem comes from pix_engine or pc-keyboard or other logic.

Copy/paste from debug for ², < and A:

[2023-10-11T20:32:30Z DEBUG pix_engine::engine] Polling event KeyDown { key: None, keymod: NONE, repeat: false }
[2023-10-11T20:32:30Z DEBUG pix_engine::engine] Polling event TextInput { text: "²" }
[2023-10-11T20:32:30Z DEBUG pix_engine::engine] Polling event KeyUp { key: None, keymod: NONE, repeat: false }
[2023-10-11T20:32:44Z DEBUG pix_engine::engine] Polling event KeyDown { key: Some(Less), keymod: NONE, repeat: false }
[2023-10-11T20:32:44Z DEBUG pix_engine::engine] Polling event TextInput { text: "<" }
[2023-10-11T20:32:44Z DEBUG neotron_desktop_bios] hid_get_event() -> KeyPress(X)
[2023-10-11T20:32:44Z DEBUG pix_engine::engine] Polling event KeyUp { key: Some(Less), keymod: NONE, repeat: false }
[2023-10-11T20:32:44Z DEBUG neotron_desktop_bios] hid_get_event() -> KeyRelease(X)
[2023-10-11T20:33:06Z DEBUG pix_engine::engine] Polling event KeyDown { key: Some(A), keymod: NONE, repeat: false }
[2023-10-11T20:33:06Z DEBUG pix_engine::engine] Polling event TextInput { text: "a" }
[2023-10-11T20:33:06Z DEBUG neotron_desktop_bios] hid_get_event() -> KeyPress(A)
[2023-10-11T20:33:06Z DEBUG pix_engine::engine] Polling event KeyUp { key: Some(A), keymod: NONE, repeat: false }
[2023-10-11T20:33:06Z DEBUG neotron_desktop_bios] hid_get_event() -> KeyRelease(A)
thejpster commented 11 months ago

How does your AZERTY keyboard work if you set the pc-keyboard layout to Us104?

CHiPs44 commented 11 months ago

With Us104Key, A key gives A and so on, which is a little surprising, no?

[2023-10-12T20:31:21Z DEBUG pix_engine::engine] Polling event KeyDown { key: Some(A), keymod: NONE, repeat: false }
[2023-10-12T20:31:21Z DEBUG pix_engine::engine] Polling event TextInput { text: "a" }
[2023-10-12T20:31:21Z DEBUG neotron_desktop_bios] hid_get_event() -> KeyPress(A)
[2023-10-12T20:31:21Z DEBUG pix_engine::engine] Polling event KeyUp { key: Some(A), keymod: NONE, repeat: false }
[2023-10-12T20:31:21Z DEBUG neotron_desktop_bios] hid_get_event() -> KeyRelease(A)
thejpster commented 11 months ago

This is down to Windows (or whatever OS) doing the layout translation, and pixengine producing "key events" after this translation has been performed. The BIOS is supposed to supply the keyboard scancodes labelled as they would be on a US keyboard; i.e. without layout translation.

I suggest a note in the docs saying to use the US layout when running on the Desktop BIOS.

CHiPs44 commented 10 months ago

That's not good either, as the upper row of keys produce digits, which isn't the case on a french keyboard, and most non alphabetical keys produce either nothing or "x".

I'll stick with US or UK keyboard for now, unless there is a simple way to respect the host layout, perhaps with a special "desktop" struct converting raw "modern" keycodes to PS/2 Set1 or Set2 ones?

That would imply builds specifically intended for Neotron-Desk-BIOS unless API and shell have an entry for selecting a keyboard layout that would be saved in NVRAM for convenience.

thejpster commented 10 months ago

The OS should have a UI for selecting the layout in the config command. I don't love the idea of a Desktop BIOS specific layout but I can live with it if it works on Windows, macOS and Linux. I'd prefer fixing up the key codes in the desktop BIOS though.

CHiPs44 commented 10 months ago

After a search that made me understand your comment above, pix-engine does not use scancodes from SDL2, but keycodes that are already translated with the current locale setting.

That's why A key gives a A with UK or US layout as the desktop BIOS does not even get the scancode associated with the Q scancode...

It does not seem that pix-engine is using scancodes anywhere (didn't find it in source).

In fact, this issue should be moved to Neotron-Desktop-BIOS and an issue could be raised against pix-engine?

CHiPs44 commented 10 months ago

I forked pix-engine, cf. https://github.com/CHiPs44/pix-engine/tree/chips44-scancode, and I'll try to add scancodes to it.

As I'm a rookie at Rust, don't be afraid if I ask silly questions...

First would be: "how can I reference my local fork in Cargo.toml?" (unless https://stackoverflow.com/questions/33025887/how-to-use-a-local-unpublished-crate is still accurate).

thejpster commented 10 months ago

foobar = { path = "../foobar" }

CHiPs44 commented 10 months ago

I made a fork of pix-engine to add scancode in it: https://github.com/CHiPs44/pix-engine/tree/chips44-scancode.

For now, I'm stalled at using it in Neotron-Pico-BIOS, more news tonight if I find time!

CHiPs44 commented 10 months ago

I found time, and it works!

I have to polish key bindings as I just copied keycode enum to scancode enum in a barbaric way and some keys don't do what they are supposed to, like ² at upper corner or </> near left shift.

I will then have to submit a PR to pix-engine, and wait for it to be accepted before I submit a PR to Neotron-Desktop-BIOS.

CHiPs44 commented 10 months ago

WIP: https://github.com/CHiPs44/Neotron-Desktop-BIOS/tree/chips44-scancode

CHiPs44 commented 10 months ago

I managed to find a mapping for ² which is SDL Grave to PS/2 Set2 oem8 of pc_keyboard, but I can't find one for < between LShift and W/Z which SDL sees as NonUsBackslash.

https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf is not very helpful, calling this one Europe 2... Europe 1 is Oem5 for pc_keyboard and gives * or µ as intended.

CHiPs44 commented 10 months ago

TODO: see how it's done through https://github.com/86Box/86Box/issues/3259.

CHiPs44 commented 10 months ago

DosBox calls it Oem102 (see https://github.com/dosbox-staging/dosbox-staging/blob/main/include/keyboard.h#L50C26-L50C26), but I cannot find any mapping to a PS/2 scan code, be it ANSI or ISO...

Should we have AzertyANSI and AzertyISO variants in pc-keyboard?

Or get rid of ANSI variant and change actual one to ISO so SDL NonUsBackSlash can become PS/2 Oem5 for </> and SDL Backslash can represent Oem7 for */µ?

CHiPs44 commented 10 months ago

Found it!

In https://github.com/SteveBenz/PS2KeyboardHost/blob/master/src/ps2_UsbTranslator.hpp#L126C1-L126C36, Europe 2 is 0x64, looking for 0x64 in pc-keyboard's README leads to Oem10.

I added this mapping in Neotron-Desk-BIOS and pc-keyboard, recompiled Neotron-Common-BIOS and Neotron-OS (with Azerty layout) to test it.

Await PRs to pc-keyboard and pix-engine to update Neotron-Desk-BIOS, Neotron-Common-BIOS and Neotron-OS dependencies...

thejpster commented 10 months ago

I left some notes on the pc-keyboard PR. I'm not sure Oem10 or Oem102 are the key you are looking for, based on the pictures I drew: https://github.com/rust-embedded-community/pc-keyboard#102105-key-iso.

Edit: although of course other projects and protocols (Linux, USB HID spec, Windows, etc) are free to call the keys whatever they want so I do understand why this is a bit of a nightmare.