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

[Gerd Hoffmann]

  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