Ah, I understand. I can't seem to find the protocol that Tmux uses. The pipe-pain command might work, though.
On 3/25/21, Stuart Henderson <s...@spacehopper.org> wrote: > For the installer, honestly I think the only sane way is to drive it > from another OS with an existing screen reader via serial console. > > If Fenrir uses a terminal emulator library itself then it maybe possible > to get it to work with tmux, at least in a single window. It has a > "pipe-pane" command that sends the terminal output, including escape > sequences, to a process. It's normally used for logging but maybe > Fenrir could read input that way and using its terminal emulator > build up its own idea of what should be, so to say, on screen. > > See Theo's comment about the RFC 1692 TMux protocol, that is unrelated. > > On 2021/03/25 17:23, Ethin Probst wrote: >> 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 > -- Signed, Ethin D. Probst
