the direction of speakup

Wed May 8 12:31:32 EDT 2013

I think I might have addressed John when I should have said Robert.

I'm for keeping SpeakUp in the kernel.

However, without meaning any offense to anybody's hard work; something 
needs doing to get SpeakUp back on trap. Even if that is just a revamp 
of the web pages. Links are broken, the text is out of date.

In the source distro, the install script is broken.

I throw my hat in to the ring as a volunteer to help where I can.

Mike

On 08/05/2013 17:14, covici at ccs.covici.com wrote:
> 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

-- 
Michael A. Ray
Analyst/Programmer
Witley, Surrey, South-east UK

Interested in accessibility on the Raspberry Pi?
Visit: http://www.raspberryvi.org/

 From where you can join our mailing list for visually-impaired Pi hackers