[BRLTTY] make drivers a library?

[Samuel Thibault]

Nicolas Pitre, le Tue 22 Sep 2009 16:59:23 -0400, a écrit :
> On Tue, 22 Sep 2009, Samuel Thibault wrote:
> > Nicolas Pitre, le Tue 22 Sep 2009 13:32:40 -0400, a écrit :
> > > On Tue, 22 Sep 2009, Samuel Thibault wrote:
> > > > Yet another person on the NVDA list wanted to re-implement a driver for
> > > > some braille device because he doesn't want to have to run both brltty
> > > > and nvda at the same time.
> > 
> > Various reasons such as additionally mentioned in my other post
> > http://mielke.cc/pipermail/brltty/2009-September/006118.html
> > having to deal with starting/stopping two daemons at a time.
> 
> You're kidding or what?  Or maybe Windows is such a strange environment 
> that starting/stopping daemons is such a big deal?

For a casual user, it is.

> > Yes, but they don't start a service that may completely steal the screen
> > output and interfere with the VGA driver just because one has opened a
> > command line window, which is equivalent to what currently happens after
> > having installed brltty while jaws is installed.
> 
> This is of course a bug with BRLTTY.  One shouldn't have to relinquish 
> the screen output because BRLTTY is starting only to serve BrlAPI 
> requests.
> 
> In fact, I'm actually thinking that any BrlAPI user shouldn't have to 
> deal with starting BRLTTY at all.  Instead, it should be BrlAPI's 
> responsibility to start/stop BRLTTY itself as needed and shield the 
> necessary mechanic from BrlAPI users.  This way you have a single API 
> and behind the scene it could well be possible for BrlAPI to actually be 
> linked with BRLTTY without having a separate process, or be a separate 
> process with a communication pipe, etc.  In any case it is a bit silly 
> for BrlAPI users to have to know how and when to start (or not start) 
> BRLTTY.

This is _already_ what happens. When no BrlAPI client is connected,
BRLTTY doesn't take control of the braille device. When a windows
command line is opened, however, BRLTTY acts as a reader for it. A
solution could be to disable command line screen reading completely by
default.  Not a good thing for people using it as a command line screen
reader, but maybe we can consider that those are able to re-enable it.

Now, another issue is "portability" in windows terms: users want to be
able to throw nvda+brltty on a USB key and easily start them on any
computer after just plugging the key in. Yes, they could just start
brltty and then NVDA, but apparently it's still some blocker for casual
users. NVDA could start BRLTTY itself, of course, but James is reluctant
to do that due to the potential issues it could bring.

> > What if it
> > just happened that NVDA got started before the proper script that was
> > supposed to start BRLTTY once for good got a chance to run?
> 
> Then maybe BRLTTY should be smart enough to realize there is another 
> instance already running and connect to it possibly as an additional 
> BrlAPI user.  In fact, on Windows with many contenders for the braille 
> display, maybe BRLTTY should only provide the core BrlAPI service and 
> the traditional text screen translation to braille should always be made 
> into a BrlAPI client of its own.

There is no blocker to this approach (that's actually the only way on
w9x where we can't detach/reattach to consoles), it's rather a matter of
what policy we want.

> > > > As a result, I yet more and more believe that brltty should export its
> > > > drivers through a library too, even with an simple interface similar
> > > > to libbrlapi/libbraille.
> > > 
> > > Are they thinking the same about the Windows speech API?
> > 
> > The windows speech API doesn't pose access to sound card issues and
> > interference with jaws & co like access to braille devices do.
> 
> And a braille library won't solve anything either.

Indeed, but it will makes things simpler to deal for the user: two
applications using the same device. Close one, run the other, or
vice-versa. And not a service to start/stop. Yes, considering that when
NVDA is stopped BRLTTY shouldn't harm, it shouldn't be a problem but I
still see reluctancy from windows users.

> At least BrlAPI could play a central role and arbitrate access to the
> braille display, maintain a client use count and release the device
> and/or shutdown when the count goes to zero, etc.

Hopefully that could happen now that windoweyes has a BrlAPI driver,
yes.  I fear that won't generalize, however.

> This is how Windows (or PulseAudio) is using the 
> sound hardware, except that sound is mixed together, which is not 
> possible with a braille display of course.

That's what I meant by saying that sound cards don't have interference
issues.

> > > > Else I fear dispersion of hardware support
> > > > efforts.
> > > 
> > > If the effort needed to make proper integration of BRLTTY/BRLAPI for a 
> > > better NVDA user experience is greater than plain driver duplication, 
> > > then I'm afraid that making a proper library interface would be an even 
> > > greater effort (except that the effort is now shifted to BRLTTY 
> > > developers instead).
> > 
> > I'd rather see better integration too, but up to now that hasn't been
> > a success, while I can see how BRLTTY could manage to externalise its
> > drivers,
> 
> It already does.

They are in separate .sos, but they can't really sanely be used as such
in other applications, the required runtime is not so small.

> > and as I said in the other post it could be useful for other
> > cases too like grub or other kind of embedding on small devices which
> > can't afford local sockets and threads just for BrlAPI.
> 
> That is perhaps the most valuable argument for libification.  But again 
> I'd simply use the BrlAPI interface with the inter-process communication 
> layer removed instead of having yet another API.

The brlapi interface could be used as such yes.

> Should be possible to configure compilation of BRLTTY+BrlAPI to
> achieve just that without having to write interface code.

You mean by using something like a pipe inside the process itself, on
which the BrlAPI protocol will flow?  Any other solution I can see would
require interfacing.

Samuel