Yes, but Janina makes a good point, about the speaking from startup. Afaik, the only way to do that, is to have *some* hooks in the kernel; hence my hybrid idea. Luke On Thu, 17 Apr 2003, Thomas D. Ward wrote: > 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 at shellworld.net> > 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 > > > _______________________________________________ > Speakup mailing list > Speakup at braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup >
