speakup in user space (was Re: Serial conflict)

Jason White jason at jasonjgw.net
Sat Mar 5 03:06:38 EST 2011

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

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,

Ultimately it's the developers of Speakup who will collectively decide how
it evolves from here.

More information about the Speakup mailing list