On Mon, Jul 04, 2016 at 11:16:45AM +0200, Gerd Hoffmann wrote:
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.
Agreed.
[...]
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.
Right. Yeah, also not sure it's an improvement.
Does the original code flush the multi-byte sequence on a timeout? I suspect it is important that one can hit ESC without having to type another key. Also, I'd prefer to avoid backwards gotos if possible.
-Kevin