[BRLTTY] Footsteps towards better accessibility in Linux
Nicolas Pitre
nico at fluxnic.net
Wed May 21 16:33:55 UTC 2025
On Sat, 5 Apr 2025, Elias Oltmanns wrote:
> Hi all,
>
> On 2025-04-03 at 21:42:18 (+0200), Nicolas Pitre <nico at fluxnic.net> wrote:
> > My comments are inline below.
> > On Tue, 1 Apr 2025, Aura Kelloniemi wrote:
> >
> >> Most of us, I believe, are using the Linux console daily. It works quite
> >> nicely for most of us, I think. There are some issues though: most
> >> importantly, sighted people generally don't use Linux console nowadays.
> >> Linux's console infrastructure is pretty much deprecated and the code receives
> >> very little maintenance.
> >
> > I didn't see any deprecation notice yet. And the code receives little
> > maintenance because for the most part it just works!
>
> Well, if memory serves me right, Samuel had to raise the alarm rather
> forcefully in order to keep character injection working only a few years
> ago. My impression was that he may have had a hard time getting his
> patches into the main line kernel exactly because there are not many
> people comfortable touching the old code and because most users were not
> affected. It was impressive and quite a stroke of luck to the
> unsuspecting braille user that Samuel not only saw this issue coming
> very early on but also was able to provide patches and persuade people
> to merge them eventually.
Yep. I provided a little persuasion nudge too.
> The watch dog part of this will be required whatever component the
> accessibility stack relies upon, but there are good reasons to believe
> that getting patches merged into ancient parts of the linux kernel is
> and should be harder than more recent code running in user space.
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. They cover:
- Updated character double-width handling (moved from Unicode 5.0 to 16.0)
- Added support for zero-width characters
- added support for Unicode decomposition
- Display of a fallback glyph when the actual glyph is unavailable
- Native support for bracketed paste (with a hook for BRLTTY's benefit)
- Extension to obtain the cursor position on screens larger than 256x256 characters
So it is not as hard as it may seem if you are serious.
> Writing this email in Emacs within tmux running on the console right
> now, the space after 😊 gets swallowed on my braille
> display.Subsequent editing on the same line gets very confusing
> because characters change position or double on a screen refresh.
This will be fixed once you start using that new kernel.
> So, the nice thing is that we actually have a choice between sustaining
> the console experience and improving the GUI experience, the hard thing
> is to figure out where to invest our resources most effectively. That is
> why I welcome Auras initiative for this discussion.
I strongly prefer working in a console environments, which is why I've
focused my development efforts and contributions there. Working
independently, I've made useful progress. We have to recognize that
creating equivalent GUI functionality would require a team effort rather
than a solo endeavor though.
In any case, involvement is required. Nothing ever happens without it.
Nicolas
More information about the BRLTTY
mailing list