[SeaBIOS] [RFC PATCH 2/2] serial console, input

[Kevin O'Connor]

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