speakup in user space (was Re: Serial conflict)

William Hubbs w.d.hubbs at gmail.com
Fri Mar 4 13:52:55 EST 2011

On Fri, Mar 04, 2011 at 10:06:45AM -0800, Jacob Schmude wrote:
> 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 that.


More information about the Speakup mailing list