Hi Heinrich,
On Mon, 6 Feb 2023 at 15:18, Heinrich Schuchardt xypron.glpk@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@gmx.de wrote:
Am 5. Februar 2023 03:08:54 MEZ schrieb Simon Glass sjg@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 [..]