speakup in user space (was Re: Serial conflict)
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
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
0C1F 6A76 DC9D DD58 3383 8B5D 0E76 9600 B784 D02
On Fri, 4 Mar 2011, Jacob Schmude wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 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:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 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
>> _______________________________________________ Speakup mailing
>> list Speakup at braille.uwo.ca
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> -----END PGP SIGNATURE-----
> Speakup mailing list
> Speakup at braille.uwo.ca
More information about the Speakup