the direction of speakup

[acollins at icsmail.net]

Hello all.  If Speakup were a user space app, you could start it from
inittab, like you can brltty.  It would also be able to access the video
scrollback buffer.  

I don't think the support for isa synths needs to go away just yet. 
Believe it or not, there are still a few folks running older machines with
isa slots with isa synths in them.  Besides this, for those who really
want them, it is still possible to buy machines with isa slots, so if
you have an isa synth, you can use it in a new machine.  So I don't
think it's time to drop isa support yet.

Having said that, adding usable usb serial, and support for usb synths
should be a priority.  At this point, I find myself ambivalent about
whether speakup stays in the kernel or not.  You don't get any better
access to boot messages with software speech than you could from user
space.  If the user space Speakup could be started from inittab, then
you could still get info about file system checks and such.  The only
thing you couldn't get, which you can't get with software speech either,
is kernle panic errors.  With Speakup in the kernel, and using a
hardware synth, you can sometimes still get that info, depending on how
the kernel panics.  There have been a couple of times when this has been
a life saver for me, but it happens so rarely, that I could probably
live with the inconvenience.  Thus I'm finding myself ambivalent about
Speakup staying in the kernel.  But then I'm getting older, and
ambivalent about a lot of things.  (grin)

Gene Collins

>hmmm, I wonder if we could just add a kernel driver as though we were
>writing one for a new serial card that way we would conform to what the
>kernel devs want?  From within that, maybe you could specify the way to
>get the device to use, or maybe have some simple user space program to
>tell it the device -- this is way off the top of my head, but is
>interesting to me.  You could write drivers for speech dispatcher for
>serial synths, but getting that into an initramfs would be difficult,
>you would have to change the generation scripts for each distribution,
>etc.
>
>my $.02 (or .2 trillion with hyperinflation).
>
>William Hubbs <w.d.hubbs at gmail.com> wrote:
>
>> All,
>> 
>> let's start a new thread here to figure out what needs to be done with
>> speakup.
>> 
>> Here are my ideas and the issues I see with them:
>> 
>> 1. What should we do with support for the internal ISA synthesizers?
>> 
>> My thought is that these can be dropped.
>> 
>> 2. We basically have two choices for the serial synthesizer issues.
>> 
>> a. If we keep this code inside the kernel, the bottom line is it needs
>> to be completely rewritten and there need to be changes made on the
>> kernel side to make it work correctly.
>> This will take time, and someone here will need to
>> work closely with the kernel  developers, and we'll need to find someone
>> in the kernel community to guide us -- maybe not by writing the code for
>> us, but at least consulting with us.
>> 
>> b. If we move this code into user space, we can code it however we want,
>> and that frees us from involving the kernel team.
>> 
>> question:
>> 
>> If we move the serial code to user space, I realize there is a concern
>> about missing early boot messages. Would putting the user space daemon
>> into an initramfs solve this?  would you be able to start it early
>> enough to get all of the boot messages if it was in an initramfs?
>> 
>> William
>> 
>> _______________________________________________
>> Speakup mailing list
>> Speakup at linux-speakup.org
>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
>
>-- 
>Your life is like a penny.  You're going to lose it.  The question is:
>How do
>you spend it?
>
>         John Covici
>         covici at ccs.covici.com
>_______________________________________________
>Speakup mailing list
>Speakup at linux-speakup.org
>http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup