If the tmux server uses the TMux protocol as described in RFC 1692, it (theoretically) shouldn't be too difficult to build a screen driver that can interact with it. The pty module uses the pyte terminal emulator library, so we might even be able to subclass the `Screen` class it exposes to make it easier. I'm not sure though. I'm a blind user myself, but this might not be easy in general. My original idea was to take the installer and make calls to espeak-ng for speech synthesis. It wouldn't provide full keyboard handling and all that, but it would at least speak the prompts. The problem is that I have no idea how well that'd work.
On 3/25/21, Stuart Henderson <s...@spacehopper.org> wrote: > On 2021-03-23, Ethin Probst <harlydavid...@gmail.com> wrote: >> Apologies if this is unnecessary sending of this, but I sent this to >> the tech OpenBSD mailing list (which might've not been the right list) >> so I'm re-sending it to this one just in case. (It might've gotten >> lost too.) The original email is below: > > It did go through but I think the problem is that nobody has a good answer. > >> So I've really wanted to try OpenBSD in a non-server configuration >> where I'm not installing over the internet on a remote server but on >> the local machine, but to my knowledge the OpenBSD installation media >> has no accessibility functionality whatsoever. (I'm not even sure if >> the installed system or any of the packages therein, such as in the >> ports collection, contains accessibility software.) >> >> Therefore, I'm wondering what it would take to add accessibility to >> the console portion of OpenBSD to begin with, as that as the simplest >> interface at the moment. The Orca screen reader may work on the >> desktop. There's a screen reader for the Linx console called >> Fenrir[1], but it may require functionality that is not available in >> OpenBSD, such as libevent. I've yet to try loading Fenrir on an >> installed OpenBSD system. >> >> Thoughts as to how this all could be achieved? I'm looking particular >> at screen readers; braille displays can be accomplished through >> something like brltty. > > libevent is not a problem, dozens of programs in the OpenBSD base > system use it already. The problem for Fenrir is that it can't read > the contents of the system console display, the OpenBSD kernel > doesn't have a way to do this. > > It might not be difficult to add a simple implementation of this, > but the challenge is doing it safely, especially around permissions and > access controls. Obviously a lot of care would be needed if it was to > become part of OpenBSD itself, screen contents are often sensitive. > > BRLTTY sidesteps this by not working with the system console on OpenBSD. > It relies on a patched old version of GNU Screen that makes the > contents of the buffer available over shared memory. > Obviously this isn't ideal but it's all we have for now. > > BRLTTY isn't just for Braille terminals, it does have some > text-to-speech features too, though I have no idea how well that > works in practice, I guess it will be primitive compared to > dedicated screen reader software, but maybe still useful. > I am not certain that the text-to-speech actually works in the > OpenBSD port though. At least basic functionality worked about > 2 years ago (I tested it with the X 'test' driver when working > on the screen-shm port). > > So, thinking about what else could be done. It might be possible to > modify Fenrir to interface with screen-shm like BRLTTY does. It wouldn't > give full system console access but still better than nothing. > > A more modern way would be to find a way to interface with tmux instead. > Still no direct system console access, but at least it's in the base > OS, it already deals with sharing access between login sessions, > and would be portable to many OS. And the basic tmux design with > separate client/server processes that communicate with each other > is a much better fit for doing this than GNU Screen which is a > single program. > > > -- Signed, Ethin D. Probst
