It's easy to have more than one version of BRLTTY installed on the same system at the same time. This capability allows you to test a new version before removing the old one.
The --with-execute-root build option allows you to install the complete installed file hierarchy anywhere you want such that it's entirely self-contained. Remembering that it's best to keep all of BRLTTY's components within the root file system, you can build it like this:
./configure --with-execute-root=/brltty-3.1
make install
/brltty-3.1/bin/brltty
./configure --with-execute-root=/brltty-3.2
make install
/brltty-3.2/bin/brltty
So far, this paradigm is somewhat awkward for at least two reasons. One is that these long path names are too hard to type, and the other is that you don't want to fiddle with your system's boot sequence each time you want to switch to a different version of BRLTTY. These problems are easily solved by adding a symbolic link for the executable.
ln -s /brltty-3.1/bin/brltty /bin/brltty
ln -s /brltty-3.2/bin/brltty /bin/brltty
If you'd like to get really fancy, then introduce another level of indirection in order to make all of BRLTTY's files for any given version look like they're in all of the standard places. First, create a symbolic link through a common repointable location from each of BRLTTY's standard locations.
ln -s /brltty/bin/brltty /bin/brltty
ln -s /brltty/etc/brltty /etc/brltty
ln -s /brltty/lib/brltty /lib/brltty
/brltty to the desired version.
ln -s /brltty-3.1 /brltty
BRLTTY can run as a stand-alone executable.
Everything it needs to know can be explicitly configured at build-time
(see
Build Options).
If the data directory
(see the
--with-data-directory
and
--with-execute-root build options)
doesn't exist, then BRLTTY looks in /etc for the files it needs.
Even if any of these files don't exist at all, BRLTTY still works!
If, for some reason, you ever create the data directory
(usually /etc/brltty) by hand, it's important
to set its permissions so that only root can create files within it.
chmod 755 /etc/brltty
The screen content inspection device (usually /dev/vcsa) is required.
It should already exist unless your Linux distribution is quite old.
If necessary, you can create it with:
mknod /dev/vcsa c 7 128
chmod 660 /dev/vcsa
chown root.tty /dev/vcsa
One problem often encountered when trying to use BRLTTY in an uncertain environment like a root disk or an incomplete system is that it might not find the shared libraries (or parts thereof) which it needs. Root disks often use subset and/or outdated versions of the libraries which may be inadequate. The solution is to configure BRLTTY with the --enable-standalone-programs build option. This removes all dependencies on shared libraries, but, unfortunately, also creates a larger executable. There are a number of build options which can be used to selectively remove unneeded features from BRLTTY in order to somewhat mitigate this problem (see section Build Features).
The executable is stripped during the make install. This significantly reduces its size by removing its symbol table. You'll get a much smaller executable, therefore, if you complete the full build procedure, and then copy it from its installed location. If, however, you copy it from the build directory, it'll be way too big. Don't forget to strip it.
strip brltty
Apart from fixing bugs and supporting more types of braille displays, we hope, time permitting, to work on the following:
Locking the braille window to one line as it scrolls on the screen.
Ignore cursor motion outside the region, and set soft navigational boundaries at the edges of the region.
TODO for a more complete list.
At the time of writing (December 2001), the following problems are known:
Cursor routing is implemented as a looping sub-process which runs at reduced priority to avoid using too much cpu time. Different system loads require different settings of its parameters. The defaults work very well in a typical Unix editor on a fairly lightly loaded system, but very poorly in some other situations, e.g. over a slow serial link to a remote host.