GNOME Bugzilla – Bug 167221
Gnopernicus sends output to serial device without user configuration.
Last modified: 2005-03-23 10:03:54 UTC
Steps to reproduce: Go to desktop preferences, accessibility, assistive technology support. Select check box to enable screen reader. Gnopernicus will start sending data to the serial port even if Braille has been disabled. 1. 2. This causes a hardware synthesizer to be put in an unuseable state resulting in loss of access to the Linux console by a screen reader.3. Stack trace: Other information: This caused the Dectalk USB to become unuseable for alll access technology for both Linux and Windows screen readers. Installing the factory firmware does not resolve the problem.
I can also repeat this bug. I don't have access to a Windows system, but the problem happens on my Linux box. In my case, I can return my DECtalk express to a usable state after powering off the synth and rebooting.
Kenny, does this happen even after gnopernicus is re-configured not to use braille (or to do its braille output to something other than tty0 ?), and gnome is restarted? When gnopernicus initially is started from the 'assistive technology preferences' capplet, both braille and speech are turned on by default. Because in this 'bootstrap' case gnopernicus cannot reliably tell a braille device from a hardware synth on tty0, one expects a conflict in this case and this would not necessarily be a bug. However, if serial output is sent to tty0 even if gnopernicus is configured to send braille to a different port, or not to use braille at all, then this would of course be a bug.
I am not able to reproduce this bug. I have created a patch to check if something is read/write to/in seraila port and when port is opend and closed.
Created attachment 37453 [details] [review] proposed patch Please apply this patch and send back the output.
This problem has been clarified on gnome-accessibility-list@gnome.org discution list. The problem is that gnopernicus starts by default with braille turned on.
I said in my previous comment: "gnopernicus starts by default with braille turned on". This is not true. On a fresh installed computer, braille is turned off. It is on only if user has activated it from gnopernicus and then has closed gnopernicus with braille active. But the problem described is present in case of having braille turned on.
I suspect that Beth turned on braille support via the Assistive Technology Support dialog just as Kenny did. The real bug is not that braille was turned on, but rather is that the default braille configuration assumes a 'default' serial port (and default driver). This is not useful, because the port is not probed to confirm the presence of the device, and it can be very harmful as Beth has experienced. I think that the underlying problem of assuming a 'default' braille configuration is the one that needs fixing. The default braille configuration should not specify a serial port - and the braille output system should be smart enough to behave appropriately in this case; (1)the default gconf settings should specify 'no' serial port (2)no braille output should be sent to any serial port if none was specified in the gconf key above. As an enhancement, if case (2)is detected by gnopernicus, the braille configuration dialog should be posted. I suggest that in the non-UI-frozen branches of gnopernicus (i.e. HEAD after branching for 2.10), we add a dialog as follows: "Please select 'OK' to configure your braille device settings, or 'Cancel' to turn braille support off." [Cancel] [OK] where the [] items in brackets are buttons.
marking AP0 because this bug can cause loss-of-use of end-user hardware.
Remus, considering that this bug disables hardware, I don't think it's an RFE.
Created attachment 37829 [details] [review] proposed patch This patch includes patch for bug 148074.
Created attachment 37832 [details] [review] reworked patch
The updated patch maps port 1 to 0, port 2 to 1. But the Gnopernicus GUI allows the user to choose port 3 & 4. What about those?
From the UI, but in braille module only 2 are really mapped (to TTYNAME0 and TTYNAME1). To correct this, we have 2 choises: 1 Add 2 new names (TTYNAME2 and TTYNAME3) 2 Allow user to chose only none, port 0 and port 1 (solution implemented in patch). Peter, do you prefer first solution?
The TTYNAME logic looks suspect to me anyway - we should not be relying on 'which combobox entry number (i.e. index) is chosen', we should be parsing the combobox value for a valid int between MIN_PORT_NUMBER and MAX_PORT_NUMBER... and by MIN_PORT_NUMBER in this case I mean 'minimum _valid_ port number', so if the parsing fails (i.e. for 'none'), we don't set a port. I think we do wish to support serial ports numbered higher than 0 and 1.
Yes, I completely agree with Bill. Parse the string, and support 4 ports.
Guys, can we get an updated patch ASAP? I really wanted to request code freeze breakage to get this into gnome 2.10, but Monday is tarball day!
BTW this means that a new gnopernicus tarball is needed with any changes since the last one, by Monday. Thanks...
Pach for this bug is now part of patch for bug 167221.
My previous comment is for bug #148074.
Created attachment 38359 [details] [review] reworked patch
Comment on attachment 38359 [details] [review] reworked patch commit after testing default, ports 0 and 1, and testing with a non-latin locale
Comment on attachment 38359 [details] [review] reworked patch Patch applied on cvs head.
*** Bug 148074 has been marked as a duplicate of this bug. ***
removing 'RFE' from summary, as I don't see any justification for calling this an 'enhancement' rather than a bugfix.