[BRLTTY] Footsteps towards better accessibility in Linux

[Nicolas Pitre]

On Fri, 4 Apr 2025, Aura Kelloniemi wrote:

>  > Now if you have specific examples of double-width Unicode values that 
>  > don't display properly then please share them and I'll be happy to have 
>  > a look. That's what I'm willing to contribute.
> 
> All new double-width and zero-width Unicode code points which have been
> introduced since Unicode 5.0. That is where the console driver is at the
> moment. I don't know where I could get the list of these code points.
> 
> Also, Linux console does not support combining characters (which I need), nor
> BiDi text (which I don't need, but many do). Proper Unicode rendering (without
> alignment issues/terminal garbling) requires supporting tehm.
> 
> In Unicode a code point and a grapheme cluster are a very different thing, and
> there would be a lot to do in order to get proper Unicode support to the
> console.
> 
> If you try to edit files containing a lot of emojis, you will see the
> rendering issues. When there are a lot of zero-width characters (like
> "variation selectors"), long lines get wrapped, but any Unicode-aware editor
> thinks that the content was rendered properly and its rendering logic starts
> to work in very bad ways. Combine this with tmux or screen, and there is a
> huge mess going on in the terminal.
> 
> Also, text which uses combining diacritics has the same effect as text with
> zero-width characters as programs expect the characters to take less columns
> than what they actually do.

OK. I think I've fixed all those issues. I stole your description above 
for my cover letter and submitted a patch series here:

  https://lkml.org/lkml/2025/4/9/1952

> To solve these issues, Emacs does not render any characters on Linux console
> for which there is no glyph in the console font. This of course is just a
> partial fix and it does not work inside terminal multiplexers.

This workaround could be removed when a kernel version known to be fixed 
is detected. That is likely to be Linux v6.16.0 to be released in about 
4 months from now. Add some more delays for it or a subsequent kernel to 
trickle down into a distro. But if you're willing to compile and install 
your own kernel then it makes for a pleasant experience as those bad 
Unicode artifacts are now gone.

> The main problem is that there are not enough function key entries in the
> kernel to have a binding for all possible combinations of regular keys and
> modifiers. And because people have different needs (some may want to have
> Shift-F1, while others would prefer Shift-Ctrl-Alt-Tab) there will be no
> universal solution until this limitation is lifted.

I'll try to have a look eventually.

> Even better would be to add an escape sequence for all possible key/modifier
> combinations. But this would take more memory, and because there is a clear
> logic for how the modifiers effect the produced escape sequence, programming
> that logic would be better.

There might be a way to detect the logic and allocate additional storage 
only for those sequence that don't follow the pattern.

>  > So there you have it: a makeshift bracketed paste that takes only 30 
>  > seconds to implement. Works directly in the Linux console.
> 
> True. The only problem is that it leaves the bracketing state management to
> you and thus the implementation is not very end-user friendly.

Sure, hence the "makeshift" qualifier. At least it proves that the Linux 
console is not incompatible with it, and adding it to BRLTTY would be 
very trivial.

>  > BRLTTY itself has a built-in console emulator which can be easily 
>  > extended to keep track of whatever text attributes you want for direct 
>  > consumption for braille output. Certainly much much easier than trying 
>  > to interface with whatever other terminal emulators out there. It simply 
>  > needs someone to volunteer for the work.
> 
> Yes, it is easier, but it has open questions:
> 
> 1) How to handle the menus/dialogs of the terminal emulator?

Depends. The Linux console doesn't have any such menu.

It can be similar to the way screen or tmux let you invoke special 
features. Or it can work the same way BRLTTY handles its own menu / 
help screen already.

> 2) What is the performance/memory consumption impact of doing the terminal
> rendering twice (once by brltty-term, once by the GUI emulator)?

Logically it doesn't have to be any different than using tmux.

> 3) What terminal types does brltty-term support?

It advertises itself as "screen". So it must implement the "screen" 
terminfo type.

> 4) What is the performance/memory usage impact of running a separate BRLTTY
> instance for every terminal window/tab? Even if this is tolerable on PC, is it
> tolerable on lower-end ARMs.

It is all there for you to try out. See the brltty-term script in the 
BRLTTY repo. Oh, and my distro's brltty package has it installed as 
/usr/bin/brltty-term already.

Is it bug free? Most likely not. But Dave and/or others are likely to 
fix those that are reported.


Nicolas