Kirk Reiser <speakup at braille.uwo.ca> wrote: >If you wish to be helpful and I personally am glad of it, my >suggestion is to forget about trying to make the serial synth modules >work correctly inside the kernel and write user space drivers/programs >to read the output of the soft synth device and feed hardware synths >from user land. That should make it fairly easy to handle them >properly either rs232C or usb. Then the serial modules could be >gutted and concentrate on fixing the problems speakup has that are >show stoppers like cut-and-past bug/goto position bug and smp problem >with screwing up the order of output. It might be easier just to rewrite the whole thing in user space, or at least, to write a very minimal kernel module to handle whatever really must be inside the kernel (if there is anything). Note that it could be started from initrd.img, thus still very early in the boot process, as a user-space daemon. I'm not much of a Speakup user, so it's probably most unwise to be commenting on somebody else's project. I've tested Speakup on my laptop and noticed significant bugs, for example with the keyboard handling, which I can test further and report properly if need be. The basic symtpom is that if you hold down caps-lock, press control and enter to turn off Speakup, then release capslock, it sometimes gets locked into a mode whereby keys on the right side of the main keyboard are treated as speakup commands, even though Speakup claims to be off. I've also experienced total lock-ups of the system (with Speakup repeatedly sending characters to the synthesizer - in my case, Espeak). Being in the kernel, this can really lock up the entire system and you can't just kill it and restart as you can with user-space tools. Speakup has been a good project for a long time and I hope it doesn't die due to accumulation of bugs
