Hi,
+#define FLAG_CTRL (1<<0) +#define FLAG_SHIFT (1<<1)
+VARLOW struct {
- u8 flags;
- u8 scancode;
+} termchr[256] = {
- [ '1' ] = { .scancode = 0x02, },
I think this table should be generated at runtime from kbd.c:scan_to_keycode[]. Since it doesn't change at runtime, malloc_fseg() / GET_GLOBAL() could be used instead of VARLOW.
Ah, ok. Didn't notice this one can be used for ascii -> scancode lookups.
I'm wondering whenever it makes sense to build a reverse table. We could simply search scan_to_keycode[] instead. Sure it is slower than a table lookup, but still _way_ faster than any human can type, and we would save some real-mode memory.
Is it necessary to use process_key() here instead of injecting the keycode directly with enqueue_key()?
From a brief look at the code I think I can use enqueue_key directly without anything breaking. I'll give it a try.
+void VISIBLE16 +sercon_check_event(void)
Does this need VISIBLE16?
Don't think so, I'll drop it.
If I understand correctly, most keys are sent on the serial port as single bytes, but there are a few keys that are sent as multi-byte sequences.
Yes. Single-byte us-ascii for letters and numbers. multibyte sequences starting with ESC (0x1b) for almost everything else (function keys, cursor keys, home, end, pageup, pagedown, ...)
The list in the patch isn't complete, I've only added the most important keys for initial testing.
You may also see input with the 8th bit set, which has a high chance to be a multibyte sequence (utf8) too these days. But I think we can safely ignore any input with the 8th bit set, we can't map that to us keyboard layout anyway even if we manage to correctly identify the character typed.
There's a lot of complexity to implement buffering for that unusual case. I wonder if the buffer could be avoided - I played with it a little and came up with the below (totally untested). I'm not sure if it's an improvement.
Hmm, so you avoid the buffer by maintaining an index into termseq and matched byte count instead. Hmm. Yes, avoids the buffer and also a few cpu cycles because you can continue searching where you left off. I find the code flow harder to follow though.
cheers, Gerd