speakup in user space (was Re: Serial conflict)

Steve Holmes steve at holmesgrown.com
Fri Mar 4 19:19:30 EST 2011

I've always preferred the kernel-based solution and find it to be so
responsive and fast and I remember the days of early access to deal
with kernel panics and similar stuff.  The forced fsck's that come up
from time to time also can be tracked earlier with speakup in the
kernel with good hardware support.  I do miss that when using software
speech.  I understand the advantages of user-space solutions and I
always thought a combination could really give a super experience.
Have basic support in the kernel and have user space stuff to provide
for things like keyboard-macros, flexible speak windows and stuff.  I
really wish we could fix the serial support stuff as that was a
land-mark feature of speakup in the past.  The fact that it is
basically broken on most machines is particularly disturbing.  Why it
works on some machines and not others, really bugs me!

I wish I had the expertese to help here.

On Fri, Mar 04, 2011 at 12:54:15PM -0800, 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:
> >>
> >> -----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
> > 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