/usr/share/doc/brltty/English/BRLTTY-7.html is in brltty 5.0-2ubuntu2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools">
<TITLE>BRLTTY Reference Manual: Advanced Topics</TITLE>
<LINK HREF="BRLTTY-8.html" REL=next>
<LINK HREF="BRLTTY-6.html" REL=previous>
<LINK HREF="BRLTTY.html#toc7" REL=contents>
</HEAD>
<BODY>
<A HREF="BRLTTY-8.html">Next</A>
<A HREF="BRLTTY-6.html">Previous</A>
<A HREF="BRLTTY.html#toc7">Contents</A>
<HR>
<H2><A NAME="s7">7.</A> <A HREF="BRLTTY.html#toc7">Advanced Topics</A></H2>
<H2><A NAME="multiple"></A> <A NAME="ss7.1">7.1</A> <A HREF="BRLTTY.html#toc7.1">Installing Multiple Versions</A>
</H2>
<P>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.</P>
<P>The
<A HREF="BRLTTY-3.html#build-execute-root">--with-execute-root</A> build option allows you
to install the complete
<A HREF="BRLTTY-3.html#hierarchy">installed file hierarchy</A>
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:
<BLOCKQUOTE><CODE>
<PRE>
./configure --with-execute-root=/brltty-3.1
make install
</PRE>
</CODE></BLOCKQUOTE>
You can then run it like this:
<BLOCKQUOTE><CODE>
/brltty-3.1/bin/brltty
</CODE></BLOCKQUOTE>
When version 3.2 is released, just install it in a different location
and run the new executable from there.
<BLOCKQUOTE><CODE>
<PRE>
./configure --with-execute-root=/brltty-3.2
make install
/brltty-3.2/bin/brltty
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>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.
<BLOCKQUOTE><CODE>
ln -s /brltty-3.1/bin/brltty /bin/brltty
</CODE></BLOCKQUOTE>
When it's time to switch to the newer version, just repoint the symbolic link.
<BLOCKQUOTE><CODE>
ln -s /brltty-3.2/bin/brltty /bin/brltty
</CODE></BLOCKQUOTE>
</P>
<P>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.
<BLOCKQUOTE><CODE>
<PRE>
ln -s /brltty/bin/brltty /bin/brltty
ln -s /brltty/etc/brltty /etc/brltty
ln -s /brltty/lib/brltty /lib/brltty
</PRE>
</CODE></BLOCKQUOTE>
Then all you need to do is to point <CODE>/brltty</CODE> to the desired version.
<BLOCKQUOTE><CODE>
ln -s /brltty-3.1 /brltty
</CODE></BLOCKQUOTE>
</P>
<H2><A NAME="ss7.2">7.2</A> <A HREF="BRLTTY.html#toc7.2">Installation/Rescue Root Disks for Linux</A>
</H2>
<P>BRLTTY can run as a stand-alone executable.
Everything it needs to know can be explicitly configured at build-time
(see
<A HREF="BRLTTY-3.html#build">Build Options</A>).
If the data directory
(see the
<A HREF="BRLTTY-3.html#build-data-directory">--with-data-directory</A>
and
<A HREF="BRLTTY-3.html#build-execute-root">--with-execute-root</A> build options)
doesn't exist, then BRLTTY looks in <CODE>/etc</CODE> for the files it needs.
Even if any of these files don't exist at all, BRLTTY still works!</P>
<P>If, for some reason, you ever create the data directory
(usually <CODE>/etc/brltty</CODE>) by hand, it's important
to set its permissions so that only root can create files within it.
<BLOCKQUOTE><CODE>
chmod 755 /etc/brltty
</CODE></BLOCKQUOTE>
</P>
<P>The screen content inspection device (usually <CODE>/dev/vcsa</CODE>) is required.
It should already exist unless your Linux distribution is quite old.
If necessary, you can create it with:
<BLOCKQUOTE><CODE>
<PRE>
mknod /dev/vcsa c 7 128
chmod 660 /dev/vcsa
chown root.tty /dev/vcsa
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>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
<A HREF="BRLTTY-3.html#build-standalone-programs">--enable-standalone-programs</A> 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
<A HREF="BRLTTY-3.html#build-features">Build Features</A>).</P>
<P>The executable is stripped during the
<A HREF="BRLTTY-3.html#make-install">make install</A>.
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.
<BLOCKQUOTE><CODE>
strip brltty
</CODE></BLOCKQUOTE>
</P>
<H2><A NAME="ss7.3">7.3</A> <A HREF="BRLTTY.html#toc7.3">Future Enhancements</A>
</H2>
<P>Apart from fixing bugs and supporting more types of braille displays,
we hope, time permitting, to work on the following:
<DL>
<DT><B>Better Attribute Handling</B><DD>
<P>
<UL>
<LI>Attribute tracking.</LI>
<LI>Mixed text and attribute mode.</LI>
</UL>
</P>
<DT><B>Scroll Tracking</B><DD>
<P>Locking the braille window to one line as it scrolls on the screen.</P>
<DT><B>Better Speech Support</B><DD>
<P>
<UL>
<LI>Mixed braille and speech for faster reading of text.</LI>
<LI>Better speech navigation.</LI>
<LI>More speech synthesizers.</LI>
</UL>
</P>
<DT><B>Screen Subregions</B><DD>
<P>Ignore cursor motion outside the region,
and set soft navigational boundaries at the edges of the region.</P>
</DL>
See the file <CODE>TODO</CODE> for a more complete list.</P>
<H2><A NAME="ss7.4">7.4</A> <A HREF="BRLTTY.html#toc7.4">Known Bugs</A>
</H2>
<P>At the time of writing (December 2001), the following problems are known:</P>
<P>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.</P>
<HR>
<A HREF="BRLTTY-8.html">Next</A>
<A HREF="BRLTTY-6.html">Previous</A>
<A HREF="BRLTTY.html#toc7">Contents</A>
</BODY>
</HTML>
|