[BRLTTY] Was: Re: Linux console hacking > scroll back buffer

[Didier Spaier]

Salut Nicolas,

at the risk of beating a dead horse...

Maybe your technical and communication skills could help the scroll back buffer
of Linux virtual terminals (or consoles) to make a come back?

Désolé pour le hors sujet.

Cheers,
Didier

On 22/05/2025 18:37, Nicolas Pitre wrote:
> On Thu, 22 May 2025, Aura Kelloniemi wrote:
> 
>> Hi,
>>
>> On 2025-05-21 at 12:33 -0400, Nicolas Pitre <nico at fluxnic.net> wrote:
>>  > For the record, in the last month or so, I've contributed a total of 24 
>>  > patches modifying the Linux console that are on their way for inclusion 
>>  > in Linux v6.16.
>>
>> You seem to be very good at both convincing the kernel people, but also have
>> the knowledge of the kernel console driver.
> 
> Admittedly, I do this professionally too.
> 
>> As stated before, improved keyboard support would be my request of improvement
>> #1,
> 
> For me to be effective, I need to know what the problem is, and more 
> importantly how the current support doesn't provide what you need. We 
> brushed over this topic before but I've yet to understand the issue 
> fully.
> 
>> but there is one thing that would be easy to fix and would benefit all 
>> of us:
>>
>> Linux console does not have alternate screen support. Probably all modern
>> terminal emulators have a notion of an alternate screen buffer. Applications
>> can switch between these screen buffers with an escape sequence. This is used
>> to preserve original contents of a terminal while an interactive application
>> is running. Applications which utilize this include less, emacs, nano, mutt,
>> lynx, and almost any TUI application.
>>
>> Supporting this requires recognizing the escape sequences and allocating space
>> for the alternate screen buffer, which effectively doubles the amount of
>> memory allocated for screen contents.
> 
> Should be easy enough. The kernel has provisions for 63 virtual consoles 
> which is somewhat overkill. An unused VT could be leveraged for that 
> purpose.
> 
>> Do you Nicolas think this could be accepted, and would you like to do this?
>> This is an unfair request, of course, but if I start to look at the kernel
>> code, and start to learn the kernel API, it will take days and code quality
>> probably is not what kernel developers are expecting.
> 
> What you could do to help, though, is to get me the best documentation 
> about this feature with escape sequences, expected behavior (what 
> terminal state the alt screen should be in), how to test it, etc.
> 
>>> - Native support for bracketed paste (with a hook for BRLTTY's benefit)
>>
>> Did you add documentation for this in the console_codes man page?
> 
> I will once this support officially hits the mainline kernel. In the 
> mean time you can infer information from here:
> 
> https://lore.kernel.org/r/20250520171851.1219676-2-nico@fluxnic.net
> 
> 
> Nicolas
> _______________________________________________
> This message was sent via the BRLTTY mailing list.
> To post a message, send an e-mail to: BRLTTY at brltty.app
> For general information, go to: http://brltty.app/mailman/listinfo/brltty