On 29 Jan 2003, Kirk Reiser wrote: > 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. Of course. But if you look for used PC shops you should be able to find a great choice of extra cheap Pentiums at a price often lower than a mid range sound card. Yet those old Pentiums are powerful enough to drive a software synth. Yet blind students are often equiped with (rather should I say loaded with) heavy stuff to carry around. If they own a laptop it's way more enjoyable not to drag all sort of external peripherals with it. That's where the software synth comes really handy. And just to have a view into the future: most PCs won't have anymore serial ports nor ISA slots soon enough to hook all those hardware synths. The world is going towards USB peripherals only. So the future for all those good old hardware speech boxes is a simple dead end. That's why Speakup must focus on supporting software speech technologies or its users will be orphaned sooner or later. > Actually, I'd like to have a nice long discussion with you in person We're not too far apart you know. > 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' Well, not being a native English speaker it's easier for me to write. I don't find my spoken english as eloquent as I'd wish. > 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? Because we talk about Linux which shares the Unix philosophy. We don't have to cram the kernel because it can't be done otherwise... like they do with that other OS. The idea is simple: if it can be done in user space, do so. It will always be better for your developer's mental health. Kernel space code must be considered only if it can't be done in user space. Take x window for example: entirely user space. Web servers: user space. Those are only two examples of things that are in the kernel on Windows. On Linux we managed to make good software abstractions so those things can live in user space and still blow Windows away performance wise. > If you are taking the code expense to drive video cards of > many flavours then why not voice synthesizers? Simply because it can't be done from user space. > Console code has to support vt100 or linux terminal sequences then why not > synth control codes? Because historically Unix was used with terminals that were separate devices from the actual main computer. Applications have been written with that model for over 30 years now. When the computer <-> terminal model was transposed to a PC they made the actual console just like if it was a VT320 on a serial port. So the Linux console supports VT100 sequences just to comply with the Unix tty model and be transparent to applications that just work the same way regardless if they're interacting with the user over a network, a terminal on a serial line or on the actual same machine. I don't see speech synths fitting into that model at all. Trying to apply the tty model to them is a bit far fetched -- it was never meant for that. > If you are going to have scroll lock, numlock, print screen > and many other special keyboard functions then why not screen review > keyboard functions? Oh that's different. I never said that there shouldn't be any screen review keyboard functions. The keyboard on your PC may as well serve two purposes: be part of the terminal emulation (even if most people aren't aware of this layering happening behind the scene), and serve as a special event device for a screen review application, or any other applications for that matter. With the new input API in Linux you can do just that: open the keyboard device and have all the raw key events sent your way for your enjoyment. > Why should a blind person not deserve the same > access to the kernel that any sighted person has? They certainly do deserve that access -- don't take me wrong. It's the _implementation_ for that access that needs discussing. > 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. But if you don't have to touch it why bother? My point is that access from startup to shutdown is virtually possible from user space as well. I say "virtualy" because even sighted people don't have access to their kernel as you put it from the very begining. There is always a window where even sighted people won't have a clue on their screen if the kernel crashes simply because conventional output devices are not initialized/accessible from the very beginning either. It just happens that the code that goes all way through that window has been debugged long time ago and is pretty much unlikely to crash these days. That's the same for access technologies -- you can easily manage to have the kernel boot all way through to user space without any failure. Once there, you simply start your accessibility application as the very first user process, grab a log of what the kernel printed out before that point from /proc/kmsg, monitor screen activity from /dev/vcsa0, sniff keyboard events from /dev/input/eventX, access the spech synth through /dev/ttyS0 if serial port, /dev/usb* if USB, /dev/whatever if that's an ISA card, or launch that software library that will eventually use /dev/dsp to use the soundcard. All this can be made into an initial ramdisk. That's what Red Hat uses to load appropriate required drivers, from user space, to be able to drive that special hardware where your actual root filesystem lives. Note that all this is happening _before_ the real root is mounter and where the real life boot failures are. Loading of the ramdisk can fail? Sure! But that's the same of the kernel itself. And since both the kernel and the ramdisk are put into memory by the bootloader, you can be sure that the ramdisk will be available if the kernel is. So whether the speech solution is in the kernel or in user space just doesn't make any difference here. Oh and the initramfs support that is being merged into 2.5 at the moment will be a tar-like archive of a filesystem that will be glued to the kernel binary at compile time. This will replace the initial ramdisk and incidentally remove a _lot_ of code from the kernel, like mounting the actual root device, obtaining a dynamic IP adress from a DHCP server, etc. Plenty of things that kernel developers just don't want to see in the kernel anymore since user space can handle those tasks much better. > 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. That just won't scale. There are simply too many non-blind kernel developers out there that just don't care to preserve stable kernel interfaces for accessibility usage. They even don't care about breaking binary modules provided by big companies that have much more influence than the few blind developers that we are (I assume you are blind too?). The only thing that is assured to remain stable is the user space interface into the kernel i.e. system calls. So by making Speakup live in user space you can focus on enhancing Speakup itself while others are enhancing the kernel internals. > 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. Believe me it's the user space way. If you still have objections please tell me so I can understand them and propose a solution. This doesn't mean that the kernel will never need modifications to accommodate user space accessibility needs, but those mods must be kept to a minimum and as generic as possible. Of course some synths will require a kernel driver, like the Dectalk PC, if the hardware must be accessed directly. But the driver must only provide a read/write abstraction to the hardware, no more. User space should take care of knowing about mastering the Dectalk escape sequence simply because it doesn't need to be in the kernel. > 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. The select() support for /dev/vcsa0 as I discussed with Alan is exactly that: a really simple and small kernel modification to help user space behave better. It should be around 10 lines of kernel code. > I am certainly happy to > hear reasoned suggestions on various options. Looking forward to your reply. Nicolas