Before I embark on this message, I want to apologize for my knee jerk reaction of earlier. Although I hold all the points I made as true, I don't really feel as volatily agree as I came across. Nicolas Pitre <nico@cam.org> writes: > It's way more valuable for a blind person to have a much greater choice of > speech synths, including much cheaper ones, than having speech output from > the very milisecond the kernel starts using printk(). IMHO persisting with > a kernel solution is what actually makes second class citizens in the end. Well, there are very few hardware synths speakup does not support but it should support all of them in an ideal world. As far as a software synth and sound card being the ultimate choice because of it's relative inexpense to a hardware synth, you have to also consider that a machine powerful enough to make a software synth truly as responsive as a hardware synth costs a lot more than just dropping a sound card in a 486. So there are trade offs for each solution. > Let me say that I'm blind. I'm also one of the principal ARM Linux > developers. That's my day job. Try Google with my name if you wish. I'm > therefore pretty knoledgeable with Linux kernel development, and I do that > all day long on Linux with both braille and speech support. I also wrote a > good chunk of BRLTTY. I'm currently working on a software French speech > synth for Linux in my very little free time I have left and I intend to give > it away for free too. Nick, I am and have been very familiar with you and your work. I also agree with a lot of your reasoning and arguments. > This being said I can't agree less with what you said above, but I wanted to > make sure you don't put me in the same category and that you truly consider > what I say as coming from an experienced blind user and developer. > I really really don't understand what makes you say that. Please would you > care to enlighten me on why you're picking that stance when it's question of > user space solutions? In my opinion a fully user space Speakup would have > much more benefits and can be AS RELIABLE as the kernel solution when it's > time to give access to early kernel stuff and I'd like to pursue a technical > discussion with you on this issue. Actually, I'd like to have a nice long discussion with you in person or with speak freely at some point. I have a hard time finding the time to sit down and write out all my beliefs and perspectives in an on going discussion. I don't find I write as eloquently as I'd like. 'grin' We may have to also agree to disagree on some items as well. One of your points is that the kernel is no place for access technology. My view is why not? If you postulate that kernel console code should be in the kernel at all then where is a blink any different than a sighty? If you are taking the code expense to drive video cards of many flavours then why not voice synthesizers? Console code has to support vt100 or linux terminal sequences then why not synth control codes? If you are going to have scroll lock, numlock, print screen and many other special keyboard functions then why not screen review keyboard functions? Why should a blind person not deserve the same access to the kernel that any sighted person has? Access technology doesn't make sense or belong in the kernel is not a reason. I want blinks to have speech from power up to power down. I don't know that I'll ever accomplish that goal, but if the sighted community deserves it then so do other handicapped communities. There is nothing intrinsicly holy about the kernel and console code that we should keep our hands off. Now saying that, having to stay on top of all the kernel changes certainly gets prosaic. To that end writing it once and having it stay compatible like brltty definitely has its advantages. Maybe a better approach would be to have a separate screen review console which wouldn't need to change with each small modification to the standard console code. I need to rewrite speakups interface to the kernel for the 2.5.x and above kernels so I am trying to determine the best way to approach the rewrite. I liked Alan's suggestion of writing a select patch for vsca0 but I am not totally comfortable with the new console code yet so it is probably to early to tell for sure. I am certainly happy to hear reasoned suggestions on various options. I am also not interested in hearing suggestions from folks that do not have any experience with screen review or coding. Kirk -- Kirk Reiser The Computer Braille Facility e-mail: kirk@braille.uwo.ca University of Western Ontario phone: (519) 661-3061