Re: Gnopernicus Sending Output to Serial Device Crashes Hardware Synthesizer

[Kenny Hitt <kenny hittsjunk net>]

Hi.

I wasn't running a GUI.  When I say "text console", I mean the text
based interface you get on a Linux box when you press control-alt-fn.
Fn is a function key on the keyboard usually from f1 through f6.

A text console screen reader provides no information in a GUI.

On Mon, Feb 14, 2005 at 05:25:20PM +0000, Bill Haneman wrote:
> Kenny said (of checking the br_active gconf key:
> 
> >For the record: I configured my console screan reader to use software 
> >speech
> >through speech-dispatcher or I couldn't run this test.
> > 
> >
> You don't have to be running GNOME's gui in order to run gconftool-2.  I 
> would have thought that power-cycling your synth would have sufficed.

Actually, with speakup, I could get the DECtalk express back without
rebooting.  It requires doing the following:

Disable braille support in Gnopernicus's dialog (needed to stop
gnopernicus from writing to the serial port)

Press control-alt-function key to get to a text console which you know
for sure is at a shell or login prompt. Login to the console (if needed)

type:

echo none >/proc/speakup/synth_name

(Needed to tell speakup to switch to no synth)

Power cycle the synth

now type:

echo dectlk >/proc/speakup/synth_name

If you guessed right about the state of the text console you switched to
in the earlier step, and you haven't miss typed anything, you will have
speech again from the DECtalk express.  Remember, from the time
Gnopernicus trashed the synth, you lost access to any text console.

I can usually make this approach work, but I've been running speakup and
Linux for over 4 years.  It isn't likely a newby could pull it off,
that's why I suggested power cycling the synth and reboot as the best
solution.  Remember also, this works for speakup.  I don't know if you
could pull off something like it if you are using yasr.  On systems that
don't have a Linux kernel, a blind user is likely using yasr or
emacspeak.  If the user has a braille display, this problem might not be
such a big deal.  In the U.S. most blind users only have speech output.

Although speech-dispatcher seems to be a package in most distros, the
program needed for speakup to talk to it is still only in CVS.  Yasr can
use emacspeak servers, so the user might be running yasr with software
speech.  Still, hardware synths are more responsive and easier to get up
and running than a software synth.  The majority of speakup users use
hardware synths.


> 
> As for the dialog in question - it's not just intended for blind people, 
> it's there for gui-centric testers, admins, and setup folks too. 
> 
> While this may not be true of sysadmins, in general users of hardware 
> synths are in the minority.  Certainly we want to try to coexist with 
> hardware synths, so we wish to fix this bug, but I don't think we want 
> to discard gnopernicus' current ability to talk to braille devices in 
> its default configuration. 
> 
> Not all end-users will have console access, or be familiar with it, so 
> various bootstrapping problems remain.  The reason for the dialog is to 
> make it possible (and easy) for users to have immediate access to their 
> gui on login, without having to manually start gnopernicus at each 
> login, without feedback.   What works well for some users will cause 
> problem for others, and early adopters like yourself help us find those 
> problems.
> 

I'm sure someday a blind user can use a Linux box with only
Gnome/Gnopernicus, but that day isn't here yet.  Gnome accessibility has
come a long way in the last 2 years I've been playing with it, but it
still has some important issues to solve.  For example, I still don't
have a usable mail client or web browser in Gnome.  Because you can only
read text files a line at a time, I return to a text console when I need
to read anything that's more than a few lines.

> It would be nice to have reliable plug-and-play of hardware devices for 
> accessibility, but we don't have the necessary capability yet, 
> especially with older devices.  And even a hardware probe could have 
> caused a problem for the DECTalk, it seems.
> 

The problem happens with all hardware synths I've tested.  A DECtalk
express, a Doubletalk LT, and an Accent SA.

Text console screen readers get around this problem by only requiring
the command line the first time you start the screen reader.  The screen
reader will save the option in a config file for future startup.  The
other solution is to have the option passed to the screen reader as part
of an init script during the boot process.

> Command-line configuration has a number of drawbacks.  While you _can_ 
> use the command line to temporarily set some gnopernicus options, gconf 
> is the preferred mechanism because it is persistent and does not require 
> applications to be launched from consoles or scripts; in the GUI 
> environment, most are not.
> 

One possible solution for Gnopernicus is to require a command line for
the first time and save the config in the gconf system for future
sessions.  This solution would also allow blind users running
Gnopernicus the first time from the run dialog to have braille access
instead of just speech access.  Something like 

gnopernicus brlapi

This would tell gnopernicus to start using the brlapi interface.  
Since gnopernicus defaults to speech the first time you run it, adding
this feature would help with the situation of someone who is 
both death and blind.
When gnopernicus turns on the gconf key for accessibility, it could also
write the key to make the screen reader start up with brlapi.

Hope this helps and makes since.
          Kenny