From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a85.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by befuddled.reisers.ca (Postfix) with ESMTP id 830F81EF6B0 for ; Wed, 8 May 2013 12:31:41 -0400 (EDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 383C2BC049 for ; Wed, 8 May 2013 09:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=raspberryvi.org; h= message-id:date:from:reply-to:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= raspberryvi.org; bh=NlUXbVXgU34JaLn9WTnKiWscL/k=; b=2VV/+zFGNP+Y e8/uYew4vONlFT1SltYunAK/Xfc9qdFN6wZiJKz2xwU6uV//EwUgl5TQQmZw6k1g ODeYTE4i/TjicpUY/1jw7IJTePU9+jKATsh1wGLzYBLYbm57PYLTCy+T6uTb/wfP prvXwyzdVmUhpw1MXI5TXZ5PeLq+7xE= Received: from [192.168.1.80] (host81-135-25-129.range81-135.btcentralplus.com [81.135.25.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mike@raspberryvi.org) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 73305BC031 for ; Wed, 8 May 2013 09:31:31 -0700 (PDT) Message-ID: <518A7DE4.6030407@raspberryvi.org> Date: Wed, 08 May 2013 17:31:32 +0100 From: Mike Ray User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: speakup@linux-speakup.org Subject: Re: the direction of speakup References: <8021.1367479350@ccs.covici.com> <518A5508.8020502@gmail.com> <518A6931.6070806@math.wisc.edu> <25752.1368029641@ccs.covici.com> In-Reply-To: <25752.1368029641@ccs.covici.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: speakup@linux-speakup.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mike@raspberryvi.org, "Speakup is a screen review system for Linux." List-Id: "Speakup is a screen review system for Linux." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 16:31:46 -0000 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@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 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@gmail.com >>> >>> On 5/2/2013 3:22 AM, covici@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@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 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@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@ccs.covici.com >>>>>> _______________________________________________ >>>>>> Speakup mailing list >>>>>> Speakup@linux-speakup.org >>>>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup >>>>> _______________________________________________ >>>>> Speakup mailing list >>>>> Speakup@linux-speakup.org >>>>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup >>> _______________________________________________ >>> Speakup mailing list >>> Speakup@linux-speakup.org >>> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup >>> >> -- >> --- >> John G. Heim, 608-263-4189, jheim@math.wisc.edu >> _______________________________________________ >> Speakup mailing list >> Speakup@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