Speakup in user space, why or why not?

[Luke Yelavich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Oct 03, 2005 at 01:09:58PM EST, Lorenzo Taylor wrote:
> Take brltty as an example.  As soon as it loads into memory, the user has access
> to every character on the screen, including the login prompt, and none of it is
> in the kernel.  It can run on several different Unix-like operating systems with
> no trouble.  Any screen reader should give the same console access, which is
> what makes Speakup the best thing going right now.  The problem is cross-OS
> compatibility.  Since Speakup is entirely kernel-based, there is no way to port
> it to other operating systems or to allow new linux users who are afraid of
> compiling a kernel for the first time or who don't know how or want to deviate
> from the stock kernel of their distro to use it.

I very much agree. The only problem I see is trapping keypress events. 
But then if the locktones utility can trap capslock/numlock/scroll lock 
key presses, then it muscen't be that difficult to do.

The rebuilding of kernels is also a lot more work for those who make 
modifications of distros available for others to use, especially if the 
distribution has a heavily patched kernel, which many do.

> Take it from an avid speakup user, both with hardware speech on one computer and
> software speech on the other, I wouldn't want to use anything else for console
> speech.  I just think it would be appropriate to have a similar screen reader
> with all the functionality of Speakup without having to recompile my kernel to
> get it.  And it would also be nice to be able to run the same screen reader on
> other operating systems such as FreeBSD without having to use 2 computers.

A user-space speakup would also allow for more features such as per user 
speech and tracking settings, whether a console login is spoken or not, 
detection of whether X is running on the active console, which would 
then ensure nothing was spoken when keypress events occurred, etc.

The other big thing would be the abillity to support hardware speech 
synthesizers which use USB, or via USB to serial adapters, good for 
laptop/notebook use.

I can understand that boot messages are nice to be able to hear, however 
one could compensate by having an initrd image with the speakup daemon 
included, which would then give speech output during filesystem mount 
and checking if the user so desired. As long as the boot loader can find 
the initrd and the kernel loads it, what real need are the other boot 
messages, as one can generally look at them in the dmesg log anyway.

Thanks for bringing this up Sina, as it is something I have been 
thinking about for a long time now, especially in terms of distro 
adoption. Many distributions are reluctant to include some kernel 
patches, and are also unsure whether to build Speakup as modules or into 
the kernel itself. However, if the screen reader package was simply 
another daemon loaded during startup, I think a lot more distributions 
would include the package, and alot more distros would come up speaking 
if requested during the install.
- -- 
Luke Yelavich
GPG key: 0xD06320CE 
	 (http://www.themuso.com/themuso-gpg-key.txt)
Email & MSN: themuso at themuso.com
ICQ: 18444344
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDQKsQjVefwtBjIM4RAnJMAJ9f0f5WeQfyNs/fcyzx/M0GnhO/owCfYOb4
uo4GBvT15gII8KDU1V/Ir3I=
=A8t+
-----END PGP SIGNATURE-----