The problem with forgetting about trying to make the serial synth modules work correctly inside the kernel is that that could get me fired. Well, that may be a bit of an exaggeration. But it ain't trivial either. ----- Original Message ----- From: "Kirk Reiser" <kirk@xxxxxxxxxxxxxx> To: "Speakup is a screen review system for Linux." <speakup at braille.uwo.ca> Sent: Wednesday, March 07, 2012 4:17 PM Subject: Re: patch for serial synths > Yes, well, you have experienced exactly why I quit caring if speakup > got into the official linux kernel or not. I know a lot of folks > hoped that once speakup did manage to get in there might be help from > the kernel community to fix problems with the system but I never > believed there would be help and I still don't. I believe that unless > Samuel or someone else that has good kernel savvy decide to attack the > problems and straighten them out or find other solutions, it is just a > short period of time before speakup is back out of the kernel again. > That will leave another problem though which is speakup's entire git > repo structure has been gutted to accomodate a community that doesn't > care and who's going to piece things back together afterword? > > 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. > > That's my .0000002 bitcoins worth. > Kirk > > > On Wed, 7 Mar 2012, John Heim wrote: > >> From: "Samuel Thibault" samuel.thibault at ens-lyon.org >>> Note: it's not a proper fix, as it won't prevent you from screwing your >>> serial port if you concurrently access it through /dev/ttyS0 while >>> speakup is running, but it's probably better than nothing. >> >> Right. I had intended to mention that. I said in another message that I'd >> talk about the controversy I stirred up on the linux-kernel list last >> weekend. This is a related issue. So here goes... >> >> I signed up to the email list for kernel developers and last weekend I >> asked for help with this bug. The avice I gout was not exactly helpful. >> To tell you the truth, I found the attitude of the people on that list >> shockingly snobbish. They seemed more interested in criticizing the >> speakup developers than in helping me with the bug. In fact, I got no >> useful advice what so ever in actually fixing the bug. The patch I posted >> is the result of my own efforts to figure out what was going on and just >> make it so it would work. Screw correctness. >> >> But there was a debate on the list about the "right" way to fix speakup. >> It looked to me as if the developers offering advice didn't even >> understand what is required from speakup. Never the less, that didn't >> stop them from opining on how it should be rewritten. I was trying to >> tactfully suggest that the speakup developers must have had good reasons >> for what they did but fortunately, Samuel was there to correct many of >> their misconceptions. To tell you the truth though, I thought some of >> them should have been smacked. But, I guess you can't do that. >> >> So now I'm not entirely sure how to proceed. I think I will have to post >> my patch to the linux-kernel list to see if I can get it incorporated >> into the linux kernel code. Admittedly, its a bad fix. All it really does >> is to cut out some code that didn't work anyway. I don't know what the >> point of having speakup at all is if it doesn't work. The patch doesn't >> really make things worse than they were before unless you consider not >> working at all better than working incorrectly. >> >> Then there is the bigger question of fixing speakup so the linux kernel >> developers will approve of it and so that it can support USB synths. I >> would like to start working on that but I don't really know how to get >> started. I think its going to take some talking to the linux developers. >> I'm sure there's an answer there somewhere. If you can get video as soon >> as the kernel loads, you ought to be able to get speech via a hardware >> synth. The linux kernel sends characters to your video card >> immediately... Why can't it do the same to your hardware synth? An even >> better example is serial consoles. The linux kernel can be made to use a >> serial console immediately upon boot. So the magic is there. Its just a >> matter of figuring it out. >> >> So I think that what will have to be done is to make a plan that everyone >> can agree on. I am reluctant for obvious reasons to volunteer anyone >> else for that job. I'm willing to give it a try unless someone objects. >> >> _______________________________________________ >> Speakup mailing list >> Speakup at braille.uwo.ca >> http://speech.braille.uwo.ca/mailman/listinfo/speakup >> > > -- > Kirk Reiser The Computer Braille Facility > e-mail: kirk at braille.uwo.ca University of Western Ontario > phone: (519) 661-3061 > _______________________________________________ > Speakup mailing list > Speakup at braille.uwo.ca > http://speech.braille.uwo.ca/mailman/listinfo/speakup > >
