[PATCH v2 1/2] cli: Correct several bugs in cli_getch()

[Simon Glass]

Hi Heinrich,

On Mon, 6 Feb 2023 at 15:18, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 2/6/23 18:12, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sun, 5 Feb 2023 at 14:29, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >>
> >>
> >> Am 5. Februar 2023 03:08:54 MEZ schrieb Simon Glass <sjg at chromium.org>:
> >>> This function does not behave as expected when unknown escape sequences
> >>> are sent to it:
> >>>
> >>> - it fails to store (and thus echo) the last character of the invalid
> >>>   sequence
> >>
> >> What would be the benefit of echoing it? Is there any reason to assume that we want an output for an escape sequence that we fail to parse?
> >
> > Yes. In fact we don't even know if it is invalid or not. It is just
> > that U-Boot doesn't support it. The mimics the behaviour we used to
> > have, I believe.
>
> We should assume that escape sequences are valid as they are either
> coming from our drivers or passed from a terminal emulation to our
> serial console.
>
> When I open the eficonfig command and in the main menu I press <PG-UP>
> the program returns to the command line and a ~ is printed. The expected
> behavior is that <PG-UP> is ignored.
>
> This is the escape sequence:
> 1b 5b 35 7e
>
> cli_ch_process(0x1b) returns 0.
> cli_ch_process(0x5b) returns 0.
> cli_ch_process(0x35) returns 0x1b.
>
> This 0x1b is converted to BKEY_QUIT in bootmenu_conv_key(). For unknown
> escape sequences cli_ch_process() should return 0 and set cch->esc_len =
> 0 to minimize interference with the caller.

Hmmm...is that the behaviour we had before my patches? If so, I have
made a mistake.

>
> Mapping control sequences to characters 0x01-0x1b in cli_ch_esc() is not
> viable: F1-F12 with combined with SHIFT, ALT, CTRL, META already require
> 192 different values for representation. But that is stuff for future
> patches.

Indeed.

Regards,
Simon
[..]