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