brltty=driver,device,tableThis maps to the following command line invocation:
/bin/brltty -bdriver -ddevice -ttableIt also maps to the following set of
braille-driver driver braille-device device text-table table
/etc/brltty.conf) or the word
/dev/tts/0if using devfs).
/etc/brltty). The complete set of provided tables is the set of files whose names match the pattern
text.*.tblin the directory
.tblextension may be omitted. If a simple file name is specified then the
text.prefix may be omitted.
NABCC(North American Braille Computer Code).
All operands are optional. Trailing commas may be omitted.
brltty= boot parameter is supplied then the installer should:
Installing the BRLTTY package should automatically generate
a BRLTTY configuration file (
which corresponds to the specified boot operands.
See the bp2cf script for one way to do this.
The mapping from boot operand to configuration file directive is as follows:
3.2) looks for and interprets the
brltty=boot parameter as described above. It looks in
/proc/cmdlineif it exists (the
/procfile system has already been mounted), and in the
brlttyenvironment variable if it doesn't. The boot parameter is given a lower precedence than the command line but a higher precedence than the configuration file.
BRLTTY relies on a number of devices. These must be defined within the installer's root file system and support for them must be configured into the installer's kernel.
If the braille display is connected to a serial port then the installer should not probe that port when autodetecting hardware. This is because port probing byte sequences can render a braille display useless by interfering with its protocol. The simplest solution to this problem is to do no serial port probing at all. A better, but more complex, solution would be to analyze BRLTTY's boot parameter and to exclude the specified device from any port probing which needs to be done. Another alternative might be to not probe any device which is already in use.
Braille users usually use a feature known as cursor tracking. This feature causes the braille display (which typically only presents part of a single line from the screen) to follow the cursor, i.e. whenever the cursor moves the braille display automatically jumps to the cursor's new position. Distributions should carefully review each of their installer screens to ensure that the cursor (not just catchy highlighting) is always being placed at an appropriate location. Examples of good cursor placement include:
Since good braille support hasn't been developed yet for graphics mode,
there should be an easy way for the user to inform the installer
(ideally, the mere presence of the
brltty= boot parameter)
that it should only use text mode.
Graphically-oriented screens based on curses, slang, etc.
are okay as long as the console itself remains in text mode.
It may mean, however, that X should not be configured.
It definitely means that X should not be used.
The installed system, also, should not be configured to come up in X
unless the user has specifically requested it.
bp2cf(boot parameter to configuration file) script in BRLTTY's
Bootdiskssubdirectory converts BRLTTY's current boot parameter into configuration file directives. If the special file
/proc/cmdlineexists then the
brltty=boot parameter specified therein is used. If it doesn't exist then the
brlttyenvironment variable is used. If BRLTTY's boot parameter hasn't been specified then this script doesn't do anything.
This script accepts the following options:
-uoptions are mutually exclusive; the default is
-ooptions are mutually exclusive; the default is
-n. No other options have default values. The default function of this script, therefore, is to write to standard output those configuration directives which correspond to each specified boot operand.
We recommend that distributions use this script
within their BRLTTY package's installation processing
in order to automatically preconfigure BRLTTY during
bp2cf script which comes with the release of BRLTTY being packaged should be used.
Copying portions of the script, rather than the whole script,
into the package definition is a bad idea since:
Including the whole script is problematic for packages like rpms
wherein special package installation code can only be added
via scriptlets contained within a larger package definition file.
The main problem is that the
causes the installation scriptlet to terminate prematurely.
Here, to stimulate your imagination and inventiveness,
is how we do it for BRLTTY's rpm (as of release
%pre # The pre-install scriptlet. # If a configuration file already exists then rpm installs the new one as # <path>.rpmnew. If this is done then the .rpmnew file is overwritten if it # already exists. # There's no explicit way to tell if a configuration file has been installed # as itself or as a .rpmnew file. The way we'll figure it out, therefore, is by # erasing the .rpmnew file now so that we can see if it gets created later. rm -f /etc/brltty.conf.rpmnew %post # The post-install scriptlet. # If BRLTTY's boot parameter has been specified then update the just installed # configuration file template to reflect the options supplied thereby. # First, we need to determine which file to update. If there's a .rpmnew file # then update it since a previous configuration file must already have existed. file=/etc/brltty.conf new=$file.rpmnew [ -f $new ] && file=$new # Update the configuration file template via the Bootdisks/bp2cf script. # Include it right within this scriptlet so that it needn't be installed. # Imbed it within a subshell to ensure that it won't impact this scriptlet. ( # First, set bp2cf's command line arguments. set -- -u -f $file # Now run it by simply imbedding it right here. )
# If a braille display is being used then start it now. [ -x /bin/brltty ] && /bin/brlttyNote that BRLTTY, by default, puts itself into the background so there's no need to explicitly do this in the script.
The most common problems which occur during system startup tend to be those related to the lack of file system integrity. BRLTTY should be started, therefore, before the fscks are done.
BRLTTY relies on a number of devices. Distributions which use devfs should not start BRLTTY until after devfs has been activated.
Distributions which fork the initial system startup script, e.g. via initlog, should not start BRLTTY until after this fork has been done.
Braille displays can become confused by port probing byte sequences.
System hardware detection/configuration packages like kudzu
are known to cause problems in this area.
One solution is to start BRLTTY only after all such port probing has been completed.
This approach is usually inadequate, though, because it tends to impair
the ability of a blind person to handle early system startup problems
(see fsck paragraph above).
Since most braille displays use a serial port connection,
a better approach may be to disable serial port probing.
For kudzu, this would mean using its
If BRLTTY can safely be started before any other system initialization is performed,
then it can be started by inserting the following lines into
# Start the braille display. brl::sysinit:/bin/brlttyThese lines should be placed before any other
BRLTTY (as of release
provides a mechanism whereby it can be started
as soon as the kernel is up
and before any other system activity takes place.
The trick is for the kernel to start brltty instead of init,
and for brltty to then start init.
To set this up, do:
cd brltty-release ./configure --with-init-path=/sbin/real_init make mv /sbin/init /sbin/real_init cp Programs/brltty /sbin/init
Options should be specified in the configuration file if at all possible. All the other methods are just to make BRLTTY as flexible as possible. Do NOT use command line options within a system startup script as they cannot be overridden in an emergency via the boot prompt.
BRLTTY (as of release
supports the guidelines for installers which are outlined within this document.
If the special file
/proc file system has already been mounted)
then the boot options
(the operands of the
brltty= boot parameter)
are retrieved from there.
If not, then the value of the
brltty environment variable is used.
This means that options can be specified within boot manager configuration files
This feature is very useful for
It should be avoided, however, for standard installations.
If you start BRLTTY manually from the command line and aren't sure where certain options are being specified, then, in this order, try:
grep brltty /proc/cmdline
env | grep "^BRLTTY_"
grep -v "^ *#" /etc/brltty.conf
|Screen Content Inspection||vcsa||vcc/a||Char||7||128|
|General Console Operations||console||console||Char||5||1|
|Virtual Console Operations||tty0||vc/0||Char||4||0|
|Braille Display Operations||ttyS0||tts/0||Char||4||64|