-----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-----
