speakup, 2.6.22, and the way forward

[Tomas Cerha]

Kirk Reiser wrote:
> I also happen to believe that a user space set of screen readers would
> be very useful and provide users choice of the software they use.  I
> however, am not interested in writing one.

Hello Kirk and all,

let me just add a thought to this.  I don't think that the question is
whether there are alternatives to speakup, but whether it is possible to
continue speakup development.  And I believe most people simply want
speakup to continue.

I see the requirement for reading boot messages as very valid, but I
don't think it has much to do with speakup's screen-reading
functionality.  Reading these messages is as simple as sending chunks of
text to the synthesizer as they come.  So I still see it very possible
to reduce the kernel space code to minimum and allow future inclusion of
speakup core within kernel and moving other parts of it into user space
without giving up the needed functionality.  Does that make sense?
Would you, Kirk, see any problems in this approach?

This is not only the boot messages, that we can't do in a purely
user-space screen-reader, so we definitely need some kernel-space code,
but  the question is, whether we really need to have everything in
kernel or only the necessary subset.

Thank you for your attention and best regards

Tomas