speakup in user space (was Re: Serial conflict)

Ari Moisio arimo at iki.fi
Sat Mar 5 01:59:54 EST 2011


I   have made a screen reader that almost relies  on the /dev/vcsa 
devices. There are also options to read everything that an application 
spits out to stdout but only application i have found this useful is teh 
bc calculator.

There is also a  mode to read  changing content on the screen but it's not 
very usefull either, only when monitoring slowly changin status pages.

This screen reader works completely in the user space and will start 
after use has logged in.

Application will capture keyboard input and application output bu starting 
a new shel and tapping to it's stdin  and stdout. Not very elegant 
solutions but it works for me.

The source code is awful mess  and both comment in the code are in 

mr. M01510 & guide Loadstone-GPS
hkp://wwwkeys.pgp.net B784D020
0C1F 6A76 DC9D DD58 3383 8B5D 0E76 9600  B784 D02

On Fri, 4 Mar 2011, Jacob Schmude wrote:

> Hash: SHA1
> Hi
> I don't think that's a limitation of the VCSA devices themselves, but
> rather how they are used. These devices show the screen as it
> currently is at any given time, although documentation for them is
> rather sparse. But couldn't we, rather than querying the device,
> monitor it instead for incoming text? I'll do some digging and see
> what I can find out.
> It just seems that to have speakup in the kernel even after removing
> serial support would leave us with all of the problems with none of
> the advantages remaining.
> On 03/04/2011 10:52 AM, William Hubbs wrote:
>> On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote:
>>> Hi If that were done, why have Speakup in the kernel at all?
>>> Software speech cannot be included in the kernel itself, and this
>>> would mean that hardware speech would not be able to kick in as
>>> early if needed. Also, we would then be under the limitations of
>>> user-space programs in that when a kernel panic happens, we may
>>> not be able to review it whether we're using hardware
>>> synthesizers or not. If we were to go this route, my suggestion
>>> would be to get Speakup out of the kernel entirely and convert
>>> the whole thing to user-space. I'd use an approach similar to
>>> BRLTTY, using the /dev/vcsa devices. WE wouldn't lose anything
>>> more than if serial support were removed, and the integration
>>> problems with various distributions would be completely gone. No
>>> kernel conflicts, no module versioning, none of that. It would
>>> also remove the necessity for middleware between speakup and
>>> software speech.
>> SBL uses the vcsa devices. I attempted to use this screen reader,
>> but I found very quickly that it doesn't work the way we expect
>> screen readers to work. For example, if you type the date command,
>> the next thing you hear read back to you is the command prompt. You
>> are required to use the screen review mode to find the output from
>> the command and read it. As I understand it, this is a limitation
>> of the vcsa devices.
>> The closest thing as I understand it to a user space screen reader
>> that really works is yasr, but you have to be logged in to use
>> that.
>> William
>> _______________________________________________ Speakup mailing
>> list Speakup at braille.uwo.ca
>> http://speech.braille.uwo.ca/mailman/listinfo/speakup
> Version: GnuPG v1.4.11 (GNU/Linux)
> aS+4phRmAgrGZmJhvd+qV4c9ZRZesYKsVhqTZVjyzzh57Jty3oYg0FMjATNpz20M
> fInSnpm1itL+VlzMSq0KB5lChRFLyTeuAXXMlgVE8OXaQn02F88dGY68yZTvUCq1
> MbW+Hkb56hz2A4Q8ypkc03Tle+rkZE1J0i2GlAnu3jsxI+ifDpCQSnMQ0KFC4Kzo
> Ia0C02llKD+MUjmM0WDxgBGIVpIRDEr63SP8vxU3bAqdsOA9AC6n3JudofOh8AAO
> =zJ6i
> _______________________________________________
> Speakup mailing list
> Speakup at braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

More information about the Speakup mailing list