[BRLTTY] Linux console hacking (was: Re: Footsteps towards better accessibility in Linux)

[Nicolas Pitre]

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