Aura Kelloniemi, le mer. 07 mai 2025 00:15:20 +0300, a ecrit: > On 2025-05-06 at 22:31 +0200, Samuel Thibault <[email protected]> > wrote: > > Aura Kelloniemi, le mar. 06 mai 2025 23:11:47 +0300, a ecrit: > > > I think that we could discuss decopuling these activites – i.e. > separating > > > BrlAPI server out of BRLTTY (possibly together with some additional > features). > > > > BRLTTY would then always communicate with the display(s) through BrlAPI. > > > What would be the benefit, compared to the additional latency? > > There are several. Most of them are related to usage scenarios where Linux > virtual consoles are not the only environment where the user is working. > > - Resource usage: if the user does not use VTs (or they are not available), > having a core BRLTTY that reads unused screens, parses configuration files, > manages braille tables, starts a speech driver, etc. is useless.
Nowadays the linux screen driver does almost nothing. And if opening fails, it'll just report the failure to the core and not do anything further. The rest of the core remains useful for braille rendering. > All BRLTTY's screen reading features would be just extra bloat (and would also > be additional attack surface). The linux screen would stay completely silent, without any attack way. > - Multiple displays: if the user uses multiple displays (like I sometimes do), > they cannot connect them all to the same BRLTTY instance. Running a second > BRLTTY for the second display does not help, if the user wants to use > anything that relies on BrlAPI. I don't understand: you can already set different BrlAPI server ports for the different BRLTTY instances, and tell clients which one you can to connect to. > - Separation of roles/Unix philosophy: communicating with a braille display > and providing a user interface are different tasks and they naturally belong > to different programs once the user wants to use only one of these features. Ok, but that's just a principle, not really a benefit. > - Better support for BrlAPI-enabled applications: currently it is non-trivial > to write BrlAPI applications which don't utilize BRLTTY's command set in > their input handling. ? Either they know the braille device, and use raw keycodes as you wish, or you don't know the braille device, but still can use raw keycodes and let the user define bindings on the fly, or else you can rely on something existing. That can be the brltty bindings, or something else can be set up, but that can be built on *top* of the existing brlapi rather than sticking it into the protocol. Similarly to X11's xkb which sits in clients, not the server. > - Resource usage again: if the user runs several BRLTTYs (e.g. one for > console, one for gnome-terminal, one for some other terminal emulator, etc.) > the BRLTTY binaries will all contain code for the BrlAPI server and this > code will be kept in memory, No, it won't. The OS loads it on-demand. And it shares the physical pages between all instances of it. > - Device management: whether it is adding, removing or switching a braille > display from one connetion type to another, all device management could be > done by the core server. This would mean that all clients could fluently > switch from one display to another, That is already supported. > or the user could configure the server to keep multiple displays > synced together, link different clients to control different > displays independently, or whateer. That's an entirely different thing, which can be built independently from the current brltty code: something that connects to existing brlapi servers and opens a new brlapi server port, and provides the user with ways to switch between the connections to the existing brlapi servers. We had thought about it with Sebastien decades ago, we just never took the time to implement something. Some parts of the brlapi server code can probably be reused (e.g. the packetization, already shared between the server and the client library), but not very much more. (I hope you'll admit that this isn't exactly the most common case to have several displays, and nothing in the current code *prevents* from achieving what you want, it's "just" more code that needs to be written). Samuel _______________________________________________ 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
