rust-embedded-community / pc-keyboard Goto Github PK

Hi,

thank you for maintaining this crate! 🙏

I'm following along Philipp Oppermann's blog_os and implementing my local layout(s), primarily the Finnish-Swedish QWERTY and possibly the newer Finnish multilingual one.

As I don't know the history or use cases of this crate, and to avoid creating more mess than necessary – should I create a PR for upstreaming my changes at some point, I'd like to hear your opinions on how to add new implementations for KeyboardLayout.

Currently, layouts::Us104Key seems to act as a "root layout" (probably because it was the first to be implemented?) with most others falling back on it via

// impl KeyboardLayout for X
fn map_keycode(
    &self,
    keycode: KeyCode,
    modifiers: &Modifiers,
    handle_ctrl: HandleControl,
) -> DecodedKey {
    // ...
    match keycode {
        // ...
        e => {
            let us = super::Us104Key;
            us.map_keycode(e, modifiers, handle_ctrl)
        }
    }
}

Then again, at least De105Key and No105Key duplicate certain KeyCode mappings (Escape, Backspace, Return, etc.) that already exist in Us104Key.

For me, this immediately raises at least the following questions:

1. In which cases is it appropriate to fall back on the Us104Key (or any other) layout?
2. Does it make sense to create longer (with more than 2 layouts) layout chains? For example, since the ISO layouts used in the Nordics are very similar, I could reuse most of the number key mappings of No105Key for my FiSe105Key.

EDIT:
Also, related to my number 1 above, how about writing something like this?

// impl KeyboardLayout for X
fn map_keycode(
    &self,
    keycode: KeyCode,
    modifiers: &Modifiers,
    handle_ctrl: HandleControl,
) -> DecodedKey {
    // ...
    let fallback = super::Us104Key;
    match keycode {
        // ...
        KeyCode::NumpadPeriod => {
            if modifiers.numlock {
                DecodedKey::Unicode(',')
            } else {
                fallback.map_keycode(keycode, modifiers, handle_ctrl)
            }
        }
    }
}

EDIT 2:
Then again, for consistency, one ought to do the same in many other places, e.g. for unmodified Key0...Key9, which might be worse for readability?

The struct Keyboard does three things:

• Decodes PS/2 words into bytes, doing the parity check
• Runs the Scan Code Set 1 or Scan Code Set 2 finite state machine to produce KeyEvents
• Converts Key Events into Unicode according to the selected keyboard layout

These should be three objects:

• Ps2Decoder
• ScancodeProcessor<T> where T: ScancodeSet
• EventProcessor<L> where L: Layout

This helps out the Neotron system, where these three objects live in different binaries (the BMC, the BIOS and the OS, respectively).

Your crate decodes some keys into DecodedKey::RawKey objects. The enum that you provide containing keys has a Backspace variant, but, using QEmu as my example, a backspace is decoded into unicode U+0008, and as a DecodedKey::Unicode.

Pressing Pause or PrintScreen generate a "UnknownKeyCode" error.

I would be interested in this crate providing more layouts, such as Colemak or foreign language keyboard layouts. Depending on the work needed, I would be willing to work on this, especially for Colemak. I think making it easier to add more layouts (which might need changing the internal calls?) would also be beneficial. Perhaps a tool to create the map_keycode functions from .keylayout files?

Depending on the work needed, I would be willing to work on this, especially for Colemak, as I use it in my everyday life.

Thanks in advance,
brightlySalty

On a PS/2 UK keyboard with 0.6.1:

• The #~ key produces \|
• The \| key produces #~

It's perhaps a silly question, but should this library implement USB HID scan codes, too?

Feel free to close this ASAP if I'm completely out of subject.

This follows PR #42.

It should be desirable to split Azerty layout between Azerty FR (France) and Azerty BE (Belgium), as described on https://en.wikipedia.org/wiki/AZERTY, as they are significantly different.

Belgian official layout includes some AltGr and AltGr + Shift combinations to handle otherwise not available characters like ³.

"Français (variante)" as available in GNU/Linux Ubuntu 22.04 or Debian, authorize more combinations to handle for example characters like ¹²³≤≥«»“”æÆœŒÉ, see file /usr/share/X11/xkb/symbols/fr from package xkbd-data or Debian source file https://sources.debian.org/src/xkeyboard-config/2.35.1-1/symbols/fr/. Belgian GNU/Linux keyboard has similar enhancements.

It could be a good idea to include these supplemental definitions, even if they're not displayed on the keys, and even if dead keys were to be implemented.

For now, AFNOR 2019 layout should not be included until it is more used as it requires new hardware that is still not widely available.

Feel free to amend this issue by suggesting changes, as it is much more long and complex as I intended.

It would be nice to query the Keyboard directly for the state of the CTRL or the SHIFT keys.

The name of the crate is : pc-keyboard (notice the dash)
While usage, I had to use it as: pc_keyboard (notice the underscore)

It is a issue because when I encountered your crate, i made the dependency entry in my Cargo.toml as pc_keyboard = [ver] just to discover that the Cargo paniced and the right name being pc-keyboard.

If you are calling process_keyevent, some modifiers come straight out and some don't:

• Shift - hidden
• Control - hidden
• Alt - comes out (as LAlt or RAlt)
• GUI - comes out
• RAlt2 - comes out (when Print Screen pressed)

We should be consistent. As as people might want both a Unicode decode of the alphabet keys, but also know when e.g. Left and Right shift are pressed (e.g. to control the flippers in a pinball game) it seems to make sense to always pass through the modifiers, even if we also note their new position.

We thought PrntScr produced a make code of E0 12 E0 7C in Scan Code Set 2. Actually, it's more complicated.

The keys Insert, Delete, Left Arrow, Home, End, Up Arrow, Down Arrow, Page Up, Page Down and Right Arrow should do different things on your computer depending on whether Num Lock is enabled and the state of the shift keys. Blame the IBM PC/AT trying to be compatble with the IBM PC/XT. I think?

If Num Lock is ON and both shift keys are released, the make code is prefixed with E0 12 and the break code is prefixed with E0 F0 12. If you press shift, you don't get the E0 12 prefix. This is because if you do a Shift Insert with Num Lock on

So we should treat E0 12 as an extra modifier key called Unshift and track its state, but probably not allow its state to change anything about the key decoding.

Observations

• PrtScr produces E0 12 E0 7C
• PrtScr with shift pressed produces E0 7C
• PrtScr with control pressed produces E0 7C

(the above is regardless of numlock state)

• With Num Lock off, Insert produces E0 70 regardless of shift
• With Num Lock on Insert produces E0 12 E0 70
• With Num Lock on and shift pressed Insert produces E0 70
• With Num Lock on and control pressed Insert produces E0 12 E0 70

References

http://www.quadibloc.com/comp/scan.htm - refers to unshift
"Keyboard Scan Code Specification - Microsoft" - See Note 2 for Scan Code Set 2 and Note 4