[BRLTTY] Questions about brltty and Orca

Didier Spaier didier at slint.fr
Sat Sep 9 18:22:23 EDT 2017


Le 09/09/2017 à 13:16, Dave Mielke a écrit :
> [quoted lines by Didier Spaier on 2017/09/06 at 22:20 +0200]
>
>> I prepare the next Slint version http://slint.fr
>> On that occasion I will:
>> _ upgrade brltty from 4.4 to 4.5,
> 
> I hope you mean 5.5, as that's the latest release, and, among other things, 
> much better with respect to battery drain.

Indeed, this was a typo.

>> _ make the window manager and desktops speak with Orca whenever
>>  possible. Orca and deps will be installed if speech is used during
>>  installation, else available as packages.
> 
> That means that braille won't automatically work within a graphical environment 
> if speech wasn't used during the install. Maybe the speech packages should just 
> be available on the full system if speech isn't used during the install, but, 
> in my opinion, Orca should be active if braille or speeh was used during the 
> install. This also means, of course, that Orca should be preconfigured to have 
> speech, braille, or both enabled in accordance with how the install was done.

Maybe it would be simpler to have both brltty and Orca always installed?
That would mean around 110M added, mostly for Python3 (currently we only
install Python2 by default), but after all that's acceptable, I think.

Is there an inconvenience to have always speech and braille enabled by
default, if speech was used during installation? This would make things
simpler for me.

In the previous version of the installer, brltty was only started if
"brltty=..." was found in /porc/cmdline. But now, we will always run
brltty, thus I don't know a safe way to detect if braille was used
during installation. For that reason it seems safer to always start
brltty by default in the installed system (but the user can change that
at the end of installation). I assume that the daemon don't put a
big stress on resources like RAM and CPU, right?

Speech is also always started at the beginning of installation, but then
stopped unless the user confirms that she wants to keep it. So, we will
start Orca in the installed system (for root and for the first regular
user's account created) only in that case. The user can type:
touch ~/.config/startorca # to start it executing xinitrc.*
rm  ~/.config/startorca # to not start it

I realize that my explanations are convoluted, so if you or other
readers can take the time, the simplest would be to just try a beta
of the installer, found here: http://slint.fr/testing/espeakup/

My public key is attached.

The ISO is hybrid and the installer beeps if in DOS mode.

The idea is that just pressing [Enter] allows to use braille and speech.

Feedback and suggestions for enhancement are gladly welcome.


>> 1) Compiling brltty 5.5 with speech-dispatcher installed, I had to help
>> configure find the speech-dispatcher headers with:
>> CPPFLAGS="-I/usr/include -I/usr/include/speech-dispatcher"
>> No big deal, but maybe this can be avoided modifying some file used
>> for configuration 
> 
> Yes, if this is a problem, we should fix our detection of Speech Dispatcher. 
> You must be using an in between release. We have hard-coding for where the 
> older releases were installed, and use pkg-config to find where newer releases 
> are installed. It seems that you must be using a release somewhere in between 
> these two where the newer layout is being used but a pkg-config file (.pc) 
> isn't being provided. Perhaps you could check if the release you're using does 
> provide a .pc file which, perhaps, you haven't installed on the system where 
> you build brltty.

I have downloaded http://brltty.com/archive/brltty-5.5.tar.xz
Typing from brltty-5.5 this:
find -name "*.pc"
just gives this result:
./Windows/libusb-1.0.pc

>> 2) In the source archive there is a file Autostart/Udev/brltty-wrapper
>> including this comment:
>> # This script must be installed in the udev programs directory: /usr/lib/udev/
>>
>> I did that but don't really understand this script's purpose so am not
>> sure why I need it. 
> 
> The simplest answer is because our latest udev rules invoke it rather than 
> directly invoking brltty. This, of course, leads to wondering why we need the 
> wrapper. The answer is that newer releases of udev (basically, ever since the 
> Systemd people took it over) impose a five-second timeout on any program that 
> udev directly invokes. Our wrapper does a bit of cgroup magic such that brltty 
> won't be subject to that timeout.
> 
>> Context: Slackware and its derivatives do not use systemd, and include eudev 
>> instead of udev.
> 
> I'm not familiar with eudev so am unable to comment on why those distributions 
> dno't use our wrapper. I guess eudev allows brltty to be directly invoked 
> without being unceremoniously killed after five seconds. Another possibility is 
> that euvdev may be based on an older release of udev that doesn't impose the 
> timeout.

I am not sure we need it, but I guess it won't hurt keeping it anyway.

>> 3) Orca has liblouis as optional dependency and if I understand well
>> this allows Orca to send contracted Braille to a Braille terminal. Is that 
>> right? 
> 
> Yes. Orca uses LibLouis even for uncontracted braille. In other words, Orca 
> uses LibLouis, rather than brltty's tables, to render braille. This does create 
> an inconsistency insofar as braille rendering is concerned between text and 
> graphical consoles, but, for better or worse, that's just the way it is right 
> now.
> 
>> If yes, is it widely used? I am wondering if I should provide a liblouis 
>> package and link Orca to that.
> 
> You probably should. Another reason for including it is that brltty itself, 
> i.e. in a text console, can now also use LibLouis's tables. Some users may 
> prefer this, and it could even be that LibLouis has tables for languages that 
> brltty doesn't have tables for.

Thanks, I will build and install liblouis then rebuild Orca then.

>> 4) In the above described context, do I need to ship brlAPI? so far
>> I target end users rather that developers, so I am considering not
>> installing it by default, but providing it as a package. What do you
>> think? Is it needed beyond developing new drivers or such use cases?
> 
> That depends on what's in your BrlAPI package. While you don't need to install 
> its headers and documentation, you do need to install its shared object (.so 
> file) and bindings (e.g. Orca uses BrlAPI's Python bindings).

So that would be at least brlapi, bralpi-python and brlapi-utils then?
Although, I wouldn't mind making a bundle with all included as it would
still be very small.
 
>> 5) More specifically, I see the README of ORCA v24.0, about the deps:
>> * BrlTTY           - BrlTTY support for braille (optional)
>> * BrlAPI           - BrlAPI support for braille (optional)
>>
>> Of course brltty is installed when I build Orca but what BrlAPI
>> brings to Orca in addition? 
> 
> Orca uses BrlAPI to communicate with BRLTTY. That's why, in order to use Orca, 
> you do need to install BrlAPI's shared object and also to install at least its 
> Python bindings.

Will do. 

>> 6) In the same README I see:
>> YOU ALSO NEED THE LATEST AT-SPI2, PYATSPI2 AND ATK FOR THE GNOME 3.24.x
>> RELEASES.  THEY CONTAIN VERY IMPORTANT BUG FIXES!
>>
>> However I plan to ship Orca v24.0 but we have atk and at-spi2 at
>> version 2.18, with 80 or so packages that depend on those, and
>> I have no idea of the backward compatibility of them.
>>
>> Is it a real issue to continue shipping that? Or is Orca 3.18 good enough?
> 
> I don't know. Orca uses those packages to read the graphical screen. I'm sure 
> what the Orca people are getting at is use the latest versions of those 
> packages because they'll have less bugs than earlier versions. For a specific 
> answer, though, I think you'll need to ask the Orca people.
 
I will ask them, thanks

>> 7) brltty will be started by default in the installed system if a
>> Braille device has been used during installation. 
>>
>> But we start brltty at the beginning of installation, whether or not
>> /proc/cmdline includes "brltty=..."
>>
>> What is the simplest way to know if a Braille device is in use during
>> installation even if there is no "brltty=" in the command line?
> 
> How is the installer starting brltty? Is it always running, or is it only 
> started when udev detects a braille device?

It is always running, as indicated above. The truth is, we have no
support in the installer for bluetooth, and I have zero feedback of
anyone using a serial line, so I don't know if that can work this way.

Only an USB connected device has been tested.

Besr regards,
Didier


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x60C03EEA.asc
Type: application/pgp-keys
Size: 1718 bytes
Desc: not available
URL: <http://brltty.com/pipermail/brltty/attachments/20170910/5c5cac92/attachment.bin>


More information about the BRLTTY mailing list