Skip to content

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

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

Description

@CHiPs44
CHiPs44
opened on Oct 11, 2023

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)

Activity

  1. CHiPs44
    changed the title [-]Azerty keyboard swaps A and Q and so on, many others return X[/-] [+]Azerty keyboard swaps A and Q and so on, many others return X or nothing[/+] on Oct 11, 2023

  2. thejpster commented on Oct 12, 2023

    @thejpster
    thejpster
    on Oct 12, 2023
    Member

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

  3. CHiPs44 commented on Oct 12, 2023

    @CHiPs44
    CHiPs44
    on Oct 12, 2023
    Author

    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)

  4. thejpster commented on Oct 14, 2023

    @thejpster
    thejpster
    on Oct 14, 2023
    Member

    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.

  5. CHiPs44 commented on Oct 15, 2023

    @CHiPs44
    CHiPs44
    on Oct 15, 2023
    Author

    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.

  6. thejpster commented on Oct 16, 2023

    @thejpster
    thejpster
    on Oct 16, 2023
    Member

    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.

  7. CHiPs44 commented on Oct 17, 2023

    @CHiPs44
    CHiPs44
    on Oct 17, 2023
    Author

    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?

  8. CHiPs44 commented on Oct 19, 2023

    @CHiPs44
    CHiPs44
    on Oct 19, 2023
    Author

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

  9. thejpster commented on Oct 19, 2023

    @thejpster
    thejpster
    on Oct 19, 2023
    Member

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

  10. thejpster
    transferred this issue fromNeotron-Compute/Neotron-OSon Oct 20, 2023

  11. CHiPs44 commented on Oct 24, 2023

    @CHiPs44
    CHiPs44
    on Oct 24, 2023
    Author

    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!

  12. CHiPs44 commented on Oct 24, 2023

    @CHiPs44
    CHiPs44
    on Oct 24, 2023
    Author

    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.

  13. CHiPs44
    added a commit that references this issue on Oct 25, 2023

    Use scancodes instead of keycodes Neotron-Compute#14 WIP 1

    0e21fa5

  14. CHiPs44 commented on Oct 25, 2023

    @CHiPs44
    CHiPs44
    on Oct 25, 2023
    Author

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

  15. CHiPs44 commented on Oct 26, 2023

    @CHiPs44
    CHiPs44
    on Oct 26, 2023
    Author

    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.

  16. CHiPs44 commented on Oct 26, 2023

    @CHiPs44
    CHiPs44
    on Oct 26, 2023
    Author

    TODO: see how it's done through 86Box/86Box#3259.

  17. CHiPs44
    added a commit that references this issue on Oct 26, 2023

    Use scancodes instead of keycodes Neotron-Compute#14 WIP 2

    8de72e3

  18. CHiPs44 commented on Oct 28, 2023

    @CHiPs44
    CHiPs44
    on Oct 28, 2023
    Author

    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 */µ?

  19. CHiPs44 commented on Oct 28, 2023

    @CHiPs44
    CHiPs44
    on Oct 28, 2023
    Author

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

  20. thejpster commented on Oct 28, 2023

    @thejpster
    thejpster
    on Oct 28, 2023
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions