[BRLTTY] Clickable links, virtual consoles etc. (Was Re: Footsteps towards better accessibility in Linux)

[Nicolas Pitre]

On Fri, 9 May 2025, Dave Mielke wrote:

> [quoted lines by Sébastien Hinderer on 2025/05/09 at 19:34 +0200]
> 
> >perhaps we don't even need such big consoles.
> 
> Of course we do! We should be able to connect a braille device to any sighted person's computer and have it work without reconfiguration.

Thing is...

Let's assume a standard "Full HD" monitor which is about as basic as you 
may get these days. This corresponds to a resolution of 1920x1080. If 
you get 240 columns out of it, this means 1920/240 = 8 pixels wide per 
character.

Most sighted people will tell you that such a small character font on a 
Full HD monitor is visually too tiny to be practical.

That being said, I'm in favor of extending the kernel screen size 
representation nevertheless. Implementing /dev/vcsua is one approach 
which might require some time and careful planning though.

In the short term, I'd suggest extending the current vcsa interface so 
an extended header is used whenever the current one doesn't suffice.

The current header is made of 4 bytes:
  - byte 0: screen rows (max 255)
  - byte 1: screen columns (max 255)
  - byte 2: cursor x position (max 255)
  - byte 3: cursor y position (max 255)

We can signal the presence of an extended header in different ways.

Possibility #1: make all legacy values 0
  - byte 0: legacy screen rows = 0
  - byte 1: legacy screen columns = 0
  - byte 2: legacy cursor x position = 0
  - byte 3: legacy cursor y position = 0

This would be followed by:
  - byte 4-5: new screen rows (max 65535)
  - byte 6-7: new screen columns (max 65535)
  - byte 8-9: legacy cursor x position (max 65534)
  - byte 10-11: legacy cursor y position (max 65534)

I wonder, though, what would be the impact on programs currently 
relying on the /dev/vcs interfaces. I know only about 2: BRLTTY and gpm.

Possibility #2: To make it safer, we could instead do this:
  - byte 0: legacy screen rows = 1
  - byte 1: legacy screen columns = 1
  - byte 2: legacy cursor x position = 0
  - byte 3: legacy cursor y position = 0

A 1x1 screen is nonsensical but "correct" as it should be less crash 
prone to programs that don't expect a 0x0 screen with the cursor at 0,0 
outside the actual screen area. In both cases that means those 
extension-unaware apps will suddenly stop considering partial screen 
content once this header is presented to them.

Possibility #3: saturate the legacy header to signify presence of the 
extended header:
  - byte 0: legacy screen rows = 255
  - byte 1: legacy screen columns = 255
  - byte 2: legacy cursor x position = 255
  - byte 3: legacy cursor y position = 255

Problem is that the kernel may already produce this today without 
providing the extended header. And if the extended header is inserted 
then the screen content will appear shifted with garbage at the 
beginning to those apps that don't 
expect it.

Possibility #4: open /dev/vcsa with O_LARGEFILE to enable the new 
header.

This would:

  a. always use the extended header, or
  b. use it only when necessary, per the scheme above.

Problem is that you can't tell if the kernel vcsa code responds to it 
unless (a) is implemented. Yet some libraries do use that flag 
unconditionally regardless of what the application is asking for.

Possibility #5: create an ioctl to affect the header type.

Probably the safest and simplest. Kernels that don't implement it would 
simply return an error. I'd still use the legacy header with 1,1,0,0 as 
a marker to flag out mistakes.

So my preference so far would be #5.

What do you think?


Nicolas