As I said in a previous post it may be possible to write a screen reader which would run as a system service.As such it would start as soon as the services such as sendmail, apache, postfix, got loaded. It might not have all the abilities of speakup, but I could see it being vary easy to install, expand, and wouldn't be kernel linked. Also another advantage is it could probably be ported to FreeBSD, and other operating systems. The problem is time, and man power. ----- Original Message ----- From: Luke Davis <ldavis@xxxxxxxxxxxxxx> To: <speakup at braille.uwo.ca> Sent: Wednesday, April 16, 2003 10:24 PM Subject: Kernel/user space (Was: Re: redhat problems) > Okay, since we're going to have this discussion, let's have it, under a > better subject... > > Long before I started using Speakup, I was apposed to having it in the > kernel, for all manner of reasons. > > However, after using it a bit, and learning more about how it worked, I > became less attached to that idea, and started looking at it as more of a > driver, of the display type, and thus as something that needed to be in > the kernel. At least, my arguments against it, lost some major weight. > > As it stands, I am happy with Speakup as it is--in the kernel. I still > maintain, however, that there may be a better way. > > What I am looking at (unless Kirc, et al already did), is whether a hybrid > solution is possible--part in the kernel, and part in user space. > > The only part that (and this is said with an admited lack of knowledge on > certain things, and is as such subject to change without notice) needs to > be in the kernel, is what is, at minimum, required to access the consoles, > and *maybe* talk to the synths. > I am hoping that some parts can be moved out of the kernel, while still > retaining the full functionality of Speakup as it is. At the very least, > buffering of data will be necessary. What I mean is, that when output > starts to a console (such as when booting starts), data will be buffered > until the rest of the package, or at least what is needed to speak, is > loaded, either from initrd, or from the root fs. This is necessary for > some hardware synths (DEC PC), and software synths, anyway, and as such > should not be as strange as it initially looks. > > The questions, as I see them, are: > (1) is this a feasable idea; and > (2) can enough of Speakup be moved into user space to make this worth > doing? > > I do not know the answers to those yet. > > However, that is my active idea. Pleese feel free to change my mind. > > What I am thinking, is that if this can be made to happen, the kernel > parts can be made highly stable, while the rest (managing the data which > the kernel parts provide), can be as unstable as may be necessary. > > Luke > > > On Wed, 16 Apr 2003, Janina Sajka wrote: > > > But then it wouldn't be Speakup. If you prefer it, you should consider deferring to the possibility that its presence in the kernel is the very reason you like it so > > well. > > > > Do you think you'd have access to any console if Speakup loaded further up the stack? I happen to think access to any console is a very big deal, and very much an > > equalizer. After all, everyone else has that, even if they choose not to use it. > > _______________________________________________ > Speakup mailing list > Speakup at braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup
