Hi, 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. All BRLTTY's screen reading features would be just extra bloat (and would also be additional attack surface). - 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. - 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. - 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. BRLTTY's command set works well if the application is a terminal screen reader, but this becomes a limitation if the application does something different. For example I have written an e-book reader for BrlAPI, but BRLTTY does not have commands for navigating menus, exiting contexts, activating buttons, etc. Thus the application works well only with my display and with my custom BRLTTY key bindings. Separating BrlAPI from terminal screen reading (BRLTTY) would require rethinking the interface between the application and BrlAPI 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, even though only the core instance of BRLTTY runs the server. - 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, or the user could configure the server to keep multiple displays synced together, link different clients to control different displays independently, or whateer. Compare this to the current udev-based setup where connecting a USB braille display spans a new BRLTTY instance – most likely without a BrlAPI server, and certainly without migrating old BrlAPI clients to the new server. These are just from the top of my head. I assume there are other benefits as well, as well as many issues to be resolved. But the most important point here is that if we would start using other interfaces than Linux console we would need to handle different setups with minimal hassle. The problems I listed are already present and are blocking me from using multiple devices effectively or migrating to GUI. -- Aura _______________________________________________ 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
