[quoted lines by John J. Boyer on December 3, 2001, at 00:21]
>Every time I press the
>advance bar on my Braille Lite 40 to go from the end of a line to the
>beginning of the next line a row of underscores (dots 456) flashed up and is
>then replaced by the contents of the next line.
My guess is that it's actually dots 1237. Being a deaf person, you've probably
done little to make sound work on your system. When something noteworthy, i.e.
a line wrap, happens, BRLTTY, by default, notifies its user via a short tune.
If the sound setting (see BRLTTY's preferences menu) is off, or if there's a
problem accessing the sound card, then BRLTTY (2.99) informs the user via the
brief display of a dot pattern. For "wrap down", it displays dots 1237 for 20
milliseconds. Is this what you're observing?
In the preferences menu, what are your "sound" and "tune device" settings?
>Sometimes it isn't replaced.
Altough I've neither seen nor heard of it happening yet, perhaps there's an
occasional problem with the display returning to normal after this tactile
indicator is presented.
There's also another possibility. Something may be triggering BRLTTY to go into
attribute display, rather than text display, mode. This would also cause a
similar dot pattern. Would you please run BRLTTY has follows in order to
collect some debugging information:
brltty -ldebug -n -e 2>brltty.trace
When doing this, please, to keep the debug output to a minimum, try to
reproduce the problem in as few steps as possible, and keep track of what those
steps are. Then send me both the trace file and a list of the steps.
Note that when running BRLTTY in this way, it'll not go into the background. To
terminate it, just press control-C. The -ldebug option tells it to produce more
diagnostic information. The -n option tells it to stay in the foreground. The
-e option tells it to write diagnostics to standard error. The "2>" bit tells
your shell to redirect standard error to the specified file.
>Pressing the left end of the left advance bar usually takes it away.
This, presumably, is because moving the braille window causes the underlying
system to realize that the window content is changed, thereby mandating a full
refresh.
Your statement has further stimulated my curiosity from a different angle. Does
the BrailleLite 40 have two advance bars? Our driver only supports one (which
is what the BrailleLite 18 has), and we don't have access to a BrailleLite 40
for direct testing. Perhaps, therefore, there are some signals which we're not
handling correctly with respect to the larger display?
>Sometimes when I press the right end of the right advance bar the display
>actually shows what is on the screen several lines back.
Another useful trace would be for you to just press each end of each advance
bar in a known order. We could then match up the trace with the order and
actually see what those two advance bars are doing.
>What is puzzling is that brltty works perfectly on the brlspeak
>minidistribution,
What does each end of each advance bar do in brlspeak?
--
Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the
Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me
EMail: dave@mielke.cc | Canada K2A 1H7 | if you're concerned about Hell.