GNOME.org
 

Re: Dectalk USB Parameters

Hi Kenny,
I'm glad you are moving toward resolving this with Access Solutions. I think the most critical things are: 

1. That the DECTalk Express can be "killed" with a particular sequence
   of characters sent to it.  This is fundamentally a DECTalk Express
   issue.  It doesn't really have anything to do with Gnopnericus.  Some
   other application could have done the same thing.


I have to disagree.  I have 3 hardware synths: an old DECtalk express
(serial only), a Doubletalk LT, and an Accentsa.  Enabling the screen
reader option in the assistive technology dialog will crash all 3 of
them.  In my case, the crash isn't perminent.  However, it will cause me
to loose access to my text consoles.  Gnopernicus and gnome
accessibility just isn't good enough yet to provide a blind user access
to a Linux system.  Until this changes, loosing access to the text
console is no different than you suddenly loosing your monitor.

I have 3 text console screen readers installed on this system.  All of
them are designed in such a way that the Gnopernicus problem doesn't
happen.
The point I was trying to make is that in an ideal world a serial synthesizer wouldn't be vulnerable to being "killed" by any stream of bytes sent to it. In a separate thread Mario noted that some serial synthesizers support firmware upgrades via the serial port; perhaps that is what happened here (and when I wrote in this thread yesterday, I had forgotten about this feature). 


2. That Gnopernicus by default launches wanting to talk to a particular
   Braille device, and that this is unexpected by users and can have
   unintended side effects (such as your rather catastrophic one).
There has been some discussion in this thread about Gnopernicus "probing" the serial port trying to determine which Braille device is connected. In discussions with BAUM engineering earlier today, I don't believe this to be the case. From all that I've seen in this thread and from my own familiarity with Gnopernicus, I believe that #2 above is what happened. 

Please explain this more.  Gnopernicus is clearly writing to the serial
port.
Yes, absolutely it was. The question is why was Gnopernicus writing to the serial port, and under what circumstances. Certainly in your case and Beth's case, you didn't explicitly ask Gnopernicus to write to the serial port!
Please see the discussion of this issue in bugzilla bug #167221: http://bugzilla.gnome.org/show_bug.cgi?id=167221
Further research points the finger to two things that together caused this "killer" stream of characters to be sent from Gnopernicus to your serial port and synthesizer: 

 a) Telling the GNOME desktop to start the screen reader every time you
    log in (in Assistive Technology Preferences Dialog) in turn *explicitly*
    wrote to the Gnopernicus gconf user settings telling Gnopernicus to start
    with speech *and* with Braille.  This is unexpected, unanticipated,
    and arguably wrong behavior.

 b) Gnopernicus, being told to start with Braille (but not which Braille
    device or port), assumed a Vario 20 on port 1.  This is clearly not
    a good assumption to make.
The point is that Gnopernicus tried to interact with Braille because it was told to use Braille (by the AT Pref Dialog) and, not knowing what device or port, assumed Vario 20 on port 1 (where the serial synthesizer was connected and unprepared for the strings Gnopernicus sent it).
It has been suggested that Gnopernicus NOT be launchable *initially* from the GUI, but rather that the first launching must instead be from the command line and that the options there then be taken by Gnopernicus and used thereafter. I personally think this is a mistake. Too many magnification users need it to work. We also introduce a significant impediment to localization by having Gnopernicus play a WAV file (rather than immediately default to using speech). 



If you're refering to my suggestion about adding a command lin option
for braille, then you are misunderstanding what I meant.  When I suggest
a command line for Gnopernicus, I mean something added to the command
typed in the run dialog of Gnome, not a command in a text console.
I'm a bit confused. I believe all of the command line options you can use on the text console can also be used in a run dialog. Can you be more specific? 


If by GUI, you mean the assistive technology dialog, then consider
adding the following buttons.  When "enable screen reader" is checked,
the user will be presented with the same dialog you get from option 1 of
the main menu of gnopernicus.  This will allow a sighted user to
configure Gnopernicus corectly.  For the blind user who is already
running Gnopernicus, this will be anoying, but it should solve the
problem of the screen reader trashing other access technology running on
the system.
Excellent suggestion. Another variant is to have four check boxes instead of three: "Screen reader speech", "Screen reader Braille", "Magnifier" (or "Screen reader magnification", and "On-screen keyboard".
Personally, I think the appropriate solution is to have Gnopernicus either use only BrlAPI as Braille by default with no command-line options, or to not use Braille at all by default when launched with no command-line options. 

This last statement shows you aren't as familiar with Gnopernicus as you
think.  the current behavior of Gnopernicus when started from a run
dialog in Gnome is to start with speech enabled using the Kevin voice of
the gnome-speech festival driver.  Because there isn't a command line
option to start with braille support, users who are deth blind can't get
Gnopernicus up and running without help.  I believe you could set gconf
keys from a text console, but you seem to be trying to discourage the
use of text console access.
Your Gnopernicus starts with Kevin from Festival because that is the software TTS engine you have installed. Mine starts with Kevin from FreeTTS because that is the TTS engine I have installed (and Kevin is voice #0). If the only TTS engine on my system was DECtalk (and I had the DECtalk gnome-speech driver), then Gnopernicus find and use that.
To start Gnopernicus with support for Braille use the "-b" option. To explicitly turn off speech, "-S". This overrides the users's gconf settings. You can also explicitly specify a serial port and Braille device on the command line. Below is the output from 'gnopernicus --help', which lists all of the command line options: 

%gnopernicus --help
Usage: gnopernicus [OPTION...]
  --load-modules=MODULE1,MODULE2,...     Dynamic modules to load

Help options
  -?, --help                             Show this help message
  --usage                                Display brief usage message

Application options
  -d, --default                          Launch in execution with default
                                         settings
  -b, --enable-braille                   enable braille service
  -B, --disable-braille                  enable braille service
  -s, --enable-speech                    enable speech service
  -S, --disable-speech                   disable speech service
  -m, --enable-magnifier                 enable magnifier service
  -M, --disable-magnifier                disable magnifier service
  -o, --enable-braille-monitor           enable braille monitor service
  -O, --disable-braille-monitor          disable braille monitor service
  -l, --login                            Used at login time
  -p, --braille-port=ttyS[1..4]          Serial port (ttyS)
  -e, --braille-device=DEVICE NAME       Braille Device

GTK+
  --gdk-debug=FLAGS                      Gdk debugging flags to set
  --gdk-no-debug=FLAGS                   Gdk debugging flags to unset
  --display=DISPLAY                      X display to use
  --screen=SCREEN                        X screen to use
  --sync                                 Make X calls synchronous
  --name=NAME                            Program name as used by the window
                                         manager
  --class=CLASS                          Program class as used by the window
                                         manager
  --gtk-debug=FLAGS                      Gtk+ debugging flags to set
  --gtk-no-debug=FLAGS                   Gtk+ debugging flags to unset
  --g-fatal-warnings                     Make all warnings fatal
  --gtk-module=MODULE                    Load an additional Gtk module

Bonobo activation Support
  --oaf-ior-fd=FD                        File descriptor to print IOR on
  --oaf-activate-iid=IID                 IID to activate
  --oaf-private                          Prevent registering of server with OAF

GNOME GConf Support

GNOME Library
  --disable-sound                        Disable sound server usage
  --enable-sound                         Enable sound server usage
  --espeaker=HOSTNAME:PORT               Host:port on which the sound server
                                         to use is running
  --version                              2.6.0

Session management
  --sm-client-id=ID                      Specify session management ID
  --sm-config-prefix=PREFIX              Specify prefix of saved configuration
  --sm-disable                           Disable connection to session manager

GNOME GUI Library
  --disable-crash-dialog                 Disable Crash Dialog


A deaf-blind user might start Gnopernicus thusly:
  'gnopernicus -b -p=2 -e=ECO20 -S -M'
to launch Gnopernicus without speech or magnification, and with an ECO Braille 20 on port ttyS2.
Now, having done this once, those settings would be preserved in the user's gconf database, and running 'gnopernicus' alone, without command line arguments, will use those settings (no speech, no magnification, Braille with an ECO Braille 20 on port ttyS2). 


Please consider spending more time running Gnome and it's assistive
technologys.  You really can't beat hands on experience to understand a
problem.
I'll go ahead and apologize in advance for that last statement, 

Apology accepted.

>                                                                  but it's

really frustrating when a sighted person running MS Windows posts a
message suggesting a problem with Gnome accessibility that costs me access to my computer isn't really a big deal.
I'm sorry if anything in my message suggested to you that I don't think this is a serious issue. This problem has hit multiple people, and the end-result is catastrophic (at least in one case - with Beth). In addition to ensuring that the GNOME environment is never unfriendly to AT and users of AT, however, I also feel that AT devices should be very robust. Hence my comment that one of the "most critical things" is that the DECtalk can be put into a catatonic state that requires factory intervention. That, too, seems to me to be a bug to be fixed (along with the GNOME and Gnopernicus problems that we've been discussing).
As to my use of Windows to send e-mail... Sigh. My job at Sun requires the use of a Linux system, a Solaris SPARC system, and a Solaris x86/x64 system (for my work on GNOME and Linux and Solaris accessibility), and also a Windows system (for my work on Java accessibility and StarOffice accessibility as exposed via the Java Access Bridge to Windows AT apps). Of these four systems, the first three systems are *frequently* blown away and re-installed with internal Sun builds. Only the Windows OS stays stable (with updates to Java, StarOffice, etc.), and hence is my primary (but not exclusive) e-mail client. 


One of the greatest things about switching from MS Windows to Linux for me
was finally being able to install and maintain the system without
sighted help.  In my view, anything that causes me to loose that access
is a step backward.
No argument. The key thing for me is to clearly understand what those things are that are causing that loss of access, and then to get them fixed. I am concerned that Gnopernicus was blamed for some things that weren't in fact Gnopernicus errors (e.g. that the desktop AT configuration GUI didn't make clear to the user that it would tell Gnopernicus to use Braille when the user asked for "screenreader"). 


Regards,

Peter Korn
Sun Accessibility team
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]