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 <[email protected]> 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/[email protected] > > > Nicolas > _______________________________________________ > This message was sent via the BRLTTY mailing list. > To post a message, send an e-mail to: [email protected] > For general information, go to: http://brltty.app/mailman/listinfo/brltty _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
