[frenchcast1234]

Feat/Capslock, Alt, Home, End, Delete, QWERTY, AZERTY.

Add all the points from issue #134 except the third one.

• Capslock
• Alt
• Home
• End
• Delete
• QWERTY and AZERTY configuration with keyboard <index>

Closes #134

[pepedinho]

I think we should restructure this before merging.

Scancodes are a byte stream/protocol, so I would expect a proper state machine here rather than having the state spread across multiple if statements and global flags (extended, shift_pressed, etc.).

Something along the lines of:

PS/2 bytes
    ↓
scancode state machine
    ↓
key events (keycode + pressed/released)
    ↓
modifiers / keyboard layout
    ↓
terminal / shell

The current implementation mixes all of these layers together, and the keyboard driver directly calls shell_*() functions. The driver should report KEY_UP, KEY_LEFT, KEY_DELETE, etc.; the shell/terminal should decide what those keys mean.

It would also make handling E0/E1, key releases, modifiers, and additional layouts much cleaner.

There is also a likely bug in the character mapping where c is assigned again unconditionally after the if/else, effectively overriding the Shift/Caps selection.

I don't think we need to over-engineer this, but I do think we should have a clear, explicit scancode state machine and keep the parsing, layout, and shell logic separated.

[pepedinho]

I think using an enum for the key states would be more expressive e.g. Pressed, Released.

Your implementation is missing a translation step.

The driver sends keyboard events (pressed/released), and you are trying to interpret them directly in the shell.

That isn't the shell's role.

You therefore need a component to act as a state machine that reads the events from the driver.

[ Keyboard ]
        │
        ▼ (Interupt / Raw Scan Code, ex: 0x1E)
[ Keyboard driver ]
        │
        ▼ (Key event : Press / Release)
[ Keymap / State Machine ] (Shift, Alt, Caps Lock, Layout AZERTY...)
        │
        ▼ (ASCII / Utf-8 or escaping sequences)
[ Shell]