[BRLTTY] More then one connection to brlapi

[Willie Walker]

> Jan Buchal, le Sun 12 Feb 2006 17:39:35 +0100, a écrit :
>> I have the same problem with orca now. So If I run orca first then  
>> the
>> orca works fine but if after I start the speechd-el, orca don't  
>> show on
>> braille display already. Any solution?
>
> I don't know orca's code much, but:
>
> 	PyArg_ParseTuple (args, "|ii:init", &tty, &how)
>
> 	ttyNum = brlapi_getTty(tty, 0); /* HOW = give me BRLCOMMANDS */

Much of the Orca code allows the the tty to be set dynamically,
but the first thing in the chain that sets it all off has the
value hardcoded to 7 in orca.py:

     if settings.getSetting(settings.USE_BRAILLE, False):
         try:
             braille.init(_processBrailleEvent, 7)
         except:
             debug.println(debug.LEVEL_SEVERE,
                           "Could not initialize connection to  
braille.")

We used to have this value be dynamic as well, but we ended up
hardcoding it for now because I was confused about how the API
worked.  The main issue was that we needed to be able to run
Orca from a virtual console window for testing/debugging and
we kept on forgetting to set the appropriate environment vars
to make brltty happy.  Plus, I remember there being some
"smarts" in BrlTTY that seemed to do the opposite of what I
wanted it to do, which is probably just a result of me not
understanding the API well enough.  I knew we'd have to get
back to this at some point, so maybe now is the time.  :-)

> i.e. the tty number seems to be passed somehow as python argument. You
> can probably set the correct tty somehow there. But it should  
> rather do
> just like gnopernicus:
>
> - if WINDOWSPATH is defined, then just call brlapi_getTtyPath(NULL,  
> 0, BRLCOMMANDS)  (this will be the preferred way in the future)
> - else, get the XFree86_VT property of the root window, and call
> brlapi_getTty(vt, BRLCOMMANDS);

This sounds reasonable.  I'd like to learn more about these.
Do you have a pointer to the docs on brlapi_getTtyPath?

> Btw, since brlapi is LGPL for some time already, orca could just use
> brltty/api.h API definitions rather that relying on the (possibly
> changing) ABI.

There are a couple of design goals with Orca: we'd like to be
able to build it and run it without requiring brltty to on
the machine (hence Orca's runtime resolution of brltty symbols),
and we want to be able to drive brltty from Python (hence
duplication of brltty constants in Python).  Ideally, any
ABI changes would be backwards compatible.

Will