Comments in line. Brandon McGinty-Carroll <bmmcginty at bmcginty.hopto.org> wrote: > Long message, be warned. > Just some thoughts off the top of my head. > 1. boot speech > I don't currently have a way to read messages from my system directly at boot time, as I'm using espeak. > When I need to access the console that early, I hook up a serial cable, and connect from another machine. > This brings me to my first true point. > Given no userspace migration, might we model speakups serial access on > that of the serial console driver that ships with linux? This is the way I had done it in the very beginning, but that approach seemes not to be viable -- code like that may go away sometime after boot, but some time around 2.6.14 something happened and that idea apparently did not work anymore. Also, the disadvantage of this is that only serial synths, not usb ones or anything would work that way -- what would be nice is if we could do this at the beginning and switch to something better, maybe a user space daemon once things got going -- once you could load a module. > Surely that can't be objected too by kernel dev folks. > Taking a look through the kernel sources, it seems as though the serial console driver uses the same low-level calls speakup currently uses. > (Anyone more familiar with the kernel, please correct me.) > 2. kernel panics > I haven't encountered a true oops/kernel halt moment yet. > If the message couldn't be spoken, logging it in some way might be nice, though I'm sure that would depend on the error in question. > 3. USB synths > I don't see why we couldn't use the softsynth device and write back to USB, like WH has done for espeakup. > Instead of software speech, the text would be sent back out the usb > port. More complicated than that, probably we should use speech dispatcher for this sort of thing. That is why it was invented. > 4. ISA synths > Unfortunately, the hardware to support ISA is going away (laptops and the like). > There are some ISA to USB converters, but they're a bit pricy. > See above for my thoughts on using these USB devices. > 5. userspace conversion > I've come up with the following, and attempted to confirm each point with those more in the know. > TTY=virtualConsole > 5.1 thoughts > pros: > .maintainability > I believe that more development can take place in userspace than in the kernel. > Nastyness will only affect your UL screen reading application, not cause crashes as some of these issues have. > .serial/usb access > Dealing with hahrdware will be no harder than in any other application. open, write, read, flush, close. > .programming language support > Though C is the fastest language, it need not be the only language for a given task. Currently, we're locked entirely into C because the kernel rightly requires it. > .kernel devs > Less now, less in the future, for kernel developers to have to think about, and less for us to have to work through with them. > Less compatibility issues. > That isnt' to say that anyone with kernel development has caused a problem. > However, the fewer points where we're reaching into the innerds of the machine and kernel, the better. > cons: > .time/effort > It's not going to be a quick process. > There needs to be a way to access _all of the information that speakup can currently access, which means all available TTY data. > Fortunately, we know what speakup can do, and what we want it to do, > so given sufficient reason, we can do it. I would instead use the software synth we have and just use speech dispatcher and that would beminimal change, but still give us all the access. Brltty does, however anything you want -- it will take keyboard input from a Braille display (usb hib device) etc. > I will be glad to help with coding and testing. > .kernel adoption > I don't know how kernel devs are going to feel, or if they'll care, about turning speakup into a TTY gateway (basically what I invision us having). > .boot messages > sse Gene's message below. > Those of us with soft synths don't have this currently, and there are alternatives like serial consoles. > 5.2 functionality required on the kernel side > a. screen-text pulling and pushing > Given we can read data from the kernel at sufficient speed, and send our position in each TTY back into speakup, and send data to write to each console, this is doable. > b. screen updates > We must still be notified of screen changes, in userspace. > c. keyboard > The kernel has the ability to read, block and allow key presses. These key presses need to be sen to userspace, or to our reader. > If we can find a method to do this in userspace, then all the better. > (brltty might do this, will check) > 5.3 userspace code > a. read and speak > read updated screen and speak it > b. read segment > given commands ,read specific portions of the visible screen, or other nonvisible screens > (here, screen=tty) > c. synthesizer drivers > Given the current synth drivers, the codes to send and receive text and parameters will need to be located, noted, and tested. > (I believe those of you with hw synths will either need to assist in coding, or provide your devices as test platforms.) > d. read keyboard output > If we want to move everything out of the kernel as much as possible, then key processing should take place in userspace. > (brltty might do this, will check) > e. act on tty switching > The current notifyer in speakup could alert us of this. > > > On Wed, May 01, 2013 at 11:42:38PM -0500, 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 -- 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
