Just one point of clarification here: Jason White <speakup at braille.uwo.ca> wrote: >If I were designing a screen reader for Linux, I wouldn't put it in the kernel >unless there were really no workable alternative. If I had to touch the >kernel, it would be by way of a minimal driver just to provide the necessary >interfaces. The above isn't meant as a criticism of the Speakup design, which may have been the best of the available options when it was decided upon. My point, rather, is that in today's environment there are very limited benefits to be obtained from implementing the entire screen reader in the kernel. If your kernel panics and you have a serial synthesizer, then there's an added benefit, provided that Speakup is still running after the crash. Linux supports other means of reporting kernel panics, kexec, serial cosnole, network console, and so on. Thus I'm not convinced of the importance of this particular scenario. Speakup can theoretically start very early in the boot process, but the advantage really only accrues if it is compiled into the kernel image. If it's a module, then you'll need the initrd image to be loaded before it starts, as will be the case in just about every distribution these days. In that circumstance, however, you can just as easily load a user-space screen reader in the initrd image. Hardware-based speech synthesizers are undoubtedly on the way out, and have been so for at least a decade, quite aside from the issues associated with serial port access that have given rise to this discussion. I'm an outsider to the Speakup "community", and not really qualified to assess all of the alternatives. >From my perspective, this will head in either of two possible directions. 1. Speakup developers will write kernel code to access the kernel's support for serial devices (including serial to USB converters) to solve the hardware synthesizer problem; likewise, support will be provided for synthesizers with USB interfaces. I don't know whether there is likely to be pressure from the kernel community suggesting that the whole project should be in user-space and hence it should not be accepted into the mainline. I'm not making this argument, just suggesting that it could be raised when the time comes to move Speakup out of staging and into the kernel proper. This could be a barrier to final merging, depending on the criteria applied in making that decision. 2. Alternatively, a decision will be taken to move the entire implementation, or most of it, into user space, possibly leaving behind a small kernel module if the existing interfaces don't provide everything that is needed. Obviously there'll be plenty of code rewriting involved if this option is taken up. I suppose part of the question to be considered is: how hard would it be to pursue option 1, and is that really the best way to proceed over the long term? One could argue that there's a marginal advantage in certain corner cases of a kernel-based implementation and that there's a solution here which works now, and which, moreover, has done so since the late 90s. On the other hand, an implementation in user-space can't bring down your entire system in the same way that a kernel module can, all of the device support provided by the kernel is available via /dev through interfaces that will continue to be supported; there's the possibility of supporting some of the user-space terminal emulators (such as that used by the Debian installer) if a suitable API is created; working with user-space speech servers etc., is straightforward; the implementation of the screen reader may be less complex, etc. Ultimately it's the developers of Speakup who will collectively decide how it evolves from here.
