On 07.11.22 18:18, Heinrich Schuchardt wrote: > On 11/7/22 17:41, Jan Kiszka wrote: >> On 07.11.22 17:29, Heinrich Schuchardt wrote: >>> On 11/4/22 09:06, Jan Kiszka wrote: >>>> From: Jan Kiszka <jan.kis...@siemens.com> >>>> >>>> Before clearing the screen, ensure that no previous output of firmware >>>> or UEFI programs will be overwritten on serial devices or other >>>> streaming consoles. This helps generating complete boot logs. >>>> >>>> Tested regarding multi-output against qemu-x86_defconfig. >>>> >>>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> >>>> --- >>>> lib/efi_loader/efi_console.c | 8 +++++++- >>>> 1 file changed, 7 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/lib/efi_loader/efi_console.c >>>> b/lib/efi_loader/efi_console.c >>>> index 4d08dd3763a..6ce0fcc168d 100644 >>>> --- a/lib/efi_loader/efi_console.c >>>> +++ b/lib/efi_loader/efi_console.c >>>> @@ -461,10 +461,16 @@ static efi_status_t EFIAPI >>>> efi_cout_set_attribute( >>>> } >>>> >>>> /** >>>> - * efi_cout_clear_screen() - clear screen >>>> + * efi_clear_screen() - clear screen >>>> */ >>>> static void efi_clear_screen(void) >>>> { >>>> + unsigned int row; >>>> + >>>> + /* Avoid overwriting previous outputs on streaming consoles */ >>>> + for (row = 1; row < efi_cout_modes[efi_con_mode.mode].rows; row++) >>>> + printf("\n"); >>>> + >>> >>> Scrolling on a framebuffer is a very expensive operations: For each of >>> the 135 lines of an UHD display you have to copy 32 MiB. This would >>> create a delay of multiple seconds on a slow device. >> >> Thanks for explaining this - now. I didn't observe this delay in QEMU, >> but maybe that wasn't representative > > My BananaPi is really slow on it. > >> >>> >>> So keep the patch for your debugging purposed. But we cannot merge it >>> into upstream. >> >> It's in production - we can't afford shipping without it. >> >> To avoid that this will be the last patch between full upstream and our >> device one day: Do you see a way to confine overwrite protection to real >> streaming device, UARTs and such? > > How about putting this behind a Kconfig switch?
Sounds like a plan. > > You probably should first move the cursor to the lower right corner > before sending carriage returns and then place the cursor in the upper > left corner. Otherwise you cannot be sure that you scrolled all of the > text out of the visible area. I'm scrolling based on the screen size so far. Not sure how moving the cursor should improve that. > > If you use scrolling, why would you still send an ANSI sequence for > clear screen? Indeed, that should be unneeded. Or is there a cheaper way to scroll via ANSI sequences? Jan -- Siemens AG, Technology Competence Center Embedded Linux