the direction of speakup

Wed May 8 12:14:01 EDT 2013

here here -- I use speakup all day long -- have never been able to gett
gnome reliably and I use that other operating system for web brousing
and stuff Linux will not do.

John G. Heim <jheim at math.wisc.edu> wrote:

> I totally disagree. Speakup has little purpose except for the fact
> that it runs in kernel space. First of all, there are other screen
> readers for user space. And you really need a GUI these days. I
> suppose there are people using speakup all day every day. Mutt for
> email, lynx or edbrowse for the web. But I'm sure  the vast majority
> of linux users use orca for every day tasks.
> 
> The most important feature for speakup is to bail you out when you are
> really in trouble because your server is down. I don't know what you
> do for a living but I do systems admin and I cannot live without
> speakup in kernel space. About the only thing that I can think of that
> is equivalent to simply plugging in a hardware synth and getting boot
> messages would be setting up something like a Raspberry Pie to boot
> into kermit and display serial console messages. But it wouldn't be
> the same because you'd need a keyboard for the RPI.   I don't know --
> when a server is down, the last thing I want to do is mess with all
> that stuff. I just want to plug in the hardware speech synth and press
> the print screen key.
> 
> On 05/08/13 08:37, Robert Spangler wrote:
> > I throw my vote in for putting Speakup in userspace.  As others have
> > said, if we use software speech, we aren't hearing the earliest boot
> > messages anyways.  While there are still many folks using hardware
> > speech, it seems as though the software speech trend is expanding.  In
> > addition, there are other ways of checking boot messages.  It is a
> > little disheartening, however, because being able to hear messages from
> > the start of boot time has been a major advantage to Linux users but I
> > think that getting Speakup out of the kernel will benefit us all in the
> > long run.
> >
> > Thanks,
> > Robert Spangler, B.A. in Urban Studies and Spanish
> > spangler.robert at gmail.com
> >
> > On 5/2/2013 3:22 AM, covici at ccs.covici.com wrote:
> >> If we gave up the kernel, which I would really prefer not to do, then we
> >> could use speech dispatcher and write drivers for the serial synths or
> >> usb ones.  But this is to be decided.
> >>
> >> acollins at icsmail.net wrote:
> >>
> >>> 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
> >>> _______________________________________________
> >>> Speakup mailing list
> >>> Speakup at linux-speakup.org
> >>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >>
> > _______________________________________________
> > Speakup mailing list
> > Speakup at linux-speakup.org
> > http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
> >
> 
> -- 
> ---
> John G. Heim, 608-263-4189, jheim at math.wisc.edu
> _______________________________________________
> 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