[BRLTTY] strange behavior udev and systemd

Aura Kelloniemi kaura.dev at sange.fi
Thu Nov 26 04:42:54 EST 2020


Mario Lang <mlang at blind.guru> writes:
 > Aura Kelloniemi <kaura.dev at sange.fi> writes:
 > > If I have many BRLTTYinstances running, will BrlAPI clients connect to
 > > the right BRLTTY (i.e. will the latest BRLTTY be able to override the
 > > BrlAPI server for the previously started instances)?

 > There is no way to automatically determine what the "right" BRLTTY
 > instance would be.  It depends on what the user wants.

Yes.

 > They will likely need to configure the no-api directive in the
 > respective brltty.conf to avoid conflicts.

That is exactly my point.

I'll go to further details with this explanation. Let's imagine two scenarios:

1) I usually connect my display with Bluetooth, but when its battery runs out,
I plug the USB cable for charging. Now a new BRLTTY instance i started. But
what if I had open BrlAPI connections? They are still open, but they are being
served by the BRLTTY talking to the (now non-existent) Bluetooth receiver.
Thus, I possibly need to shut down a whole X session to fix the problem. (At
least that might be the easiest solution.)

And if I restart all BrlAPI clients, they will stop functioning immediately
when I unplug the USB cable.

2) I have two displays. I'm either testing a display or I am reading the same
text with a friend. (The later is arguably a far-fetched scenario.) Now, if we
want to use an application which communicates with BRLTTY via BrlAPI, we have
a big configuration problem. It is manageable, of course, but it is not easy.

The easy way to fix the scenario #1 is by the good old way of running just one
BRLTTY instance, which has been configured with braille-device set to
bluetooth:,usb:. This way there is just one BRLTTY, one BrlAPI server, and no
configuration hassle at all.

So what I am trying to ask is this: are we really sure that starting a new
BRLTTY instance for every new USB braille display is a good idea? Mostly
people will only use one display, and this scenario is best handled (IMHO)
with one BRLTTY instance. If somebody wants to use multiple displays, they
need to do manual configuration when connecting the new display, but at least
they get to know that they also need to separately configure BrlAPI, if they
want to use it.

Another way of course would be to redesign BrlAPI's and BRLTTY's co-operation,
so that one BrlAPI server could handle more devices than just one. This would
be a lot of work though.

-- 
Aura


More information about the BRLTTY mailing list