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

[Nicolas Pitre]

On Wed, 15 Apr 2026, Samuel Thibault wrote:

> Nicolas Pitre, le mer. 15 avril 2026 11:22:34 -0400, a ecrit:
> > On Wed, 15 Apr 2026, Aura Kelloniemi wrote:
> > > On 2026-04-15 at 01:47 +0200, Samuel Thibault <samuel.thibault at ens-lyon.org> wrote:
> > >  > Nicolas Pitre, le jeu. 09 avril 2026 23:12:06 -0400, a ecrit:
> > >  > > Done — the protocol now handles grapheme clusters with a three-layer 
> > >  > > approach (single codepoint, continuation cells, overflow area) and the 
> > >  > > cell width field covers the whole cluster. See the updated design 
> > >  > > document attached.
> > > 
> > >  > I'm a bit afraid of the complexity of the dynamic allocation of the
> > >  > overflow entry. I agree that adding a limitation to 8 combining
> > >  > codepoints brings static limitation, but conversely there have been
> > >  > vulnerabilities found due to unbound combining codepoints management,
> > >  > and for easier adoption, the protocol should be quite simple.
> > > 
> > > IMHO, if there is a static limitation, it should be futureproof – i.e. insely
> > > big – like 16 or 32. But of course bumping the protocol version sometimes
> > > should be acceptable.
> > 
> > There are no static limitations,
> 
> But I'm saying that it'd be simpler for the code to introduce a
> limitation so that we can use non-dynamic arrays etc.

Simpler doesn't mean better.

As the protocol goes, if the storage needs to change, you simply alloc a 
new shm and drop the previous one. This mechanism is already needed to 
support actual screen dimension changes anyway.

Given the shm is allocated using 4KB pages, the overflow area can use 
the space between the end of the screen grid and the next 4KB boundary 
without a new shm. So if ever you need to grow the allocation, it will 
naturally grow in 4KB chunks which should be plenty and not constantly 
grow the overflow storage.

> As mentioned earlier in the thread, the known requirement for Tibetan is
> 8 cobminers. So leaving room for 16 or 32 should be plenty for all
> reasonable uses.

If you want to not bother on the terminal side and only use a static 
area that's fine - the protocol won't force you to be more 
sophisticated. But the protocol definition should not put such 
limitations in place. And on the client (BRLTTY) side this is quite easy 
as there is nothing more to do than what is needed to support screen 
size changes.


Nicolas