Thank you, Nicolas, for your work. I'm slowly but surely moving to Linux
for more things, my latest move being to purchase a BT Speak, which uses
the console with BRLTTY providing speech, with Braille input. So I'm
very glad work is still being done to improve things.
On 5/21/25 11:33 AM, Nicolas Pitre wrote:
On Sat, 5 Apr 2025, Elias Oltmanns wrote:
Hi all,
On 2025-04-03 at 21:42:18 (+0200), Nicolas Pitre <[email protected]> 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
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: [email protected]
For general information, go to: http://brltty.app/mailman/listinfo/brltty
--
Devin Prater
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: [email protected]
For general information, go to: http://brltty.app/mailman/listinfo/brltty
