Actually, now that I think about it, the conector would actually have to be a full user space synth driver, since the control codes for each synth are different. This would also solve problems like putting the synth driver to sleep while waiting for io situations. But if you move the drivers to user space, then it probably won't be long before the speakup core would move to user space too. I know Kirk is still fond of having speakup in the kernel, but I'm seriously wondering how long that can continue. Especially since the software synth stuff already has to happen in user space. I suspect I'll get some knee jerk reactions for my heretical ideas, but that's ok. If the discussion doesn't happen, ideas don't get expressed. Just throwing out thoughts. Gene >Hi all. You could write a serial connector that would read the >softsynth device, and write to the specified /dev serial device. That >would mean you couldn't start speakup until after the file systems were >mounted, but you'd be no worse off than you are now using a software >synth. Plus the serial access could access all kinds of serial devices. > >Gene > >>On Sun, Jun 27, 2010 at 01:00:40PM -0500, Christopher Brannon wrote: >>> > Is there any way you could open the port from kernel space as though you >>> > were in user space and just write to it without taking exclusive >>> > control? >> >>You can't access "/dev/ttyS0" for example the same way from kernel space >>that you do from user space. The open(), read(), write() and close() >>calls are for user space applications and we do not have access to them >>inside the kernel. >> >>To stay in kernel space, we need to convert to using the kernel's tty >>layer to access serial synthesizers. It will take a complete rewrite of >>the serial i/o routines to make this happen. >> >>Also, we need access to devices some how from within the kernel in order >>to use usb devices -- we need to be able to do the equivalent of >>open("/dev/something"), which I do not know how to do at this point. >> >>If anyone has any suggestions or patches to make this happen, they will >>be most welcome. >> >>Thanks, >> >>William >> >>_______________________________________________ >>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