Eric Oyen here… looks like some good points all around on this posting. For the most part, a kernel level speech interface can be a good thing, except when it isn't. What I wouldn't mind seeing is the addition of a speak up type module for EFI. The reason for this as that I might need to be able to troubleshoot some hardware issues and the current EFI standard doesn't include any kind of accessibility. Since EFI operates largely like a Linux-Lite environment, it shouldn't be that hard to compile a small utility for it, make sure the sound module is loaded and give us access to the text screen that is available there. This would make for a system that could be accessible to those of us with no light perception and would be terminated after exiting the EFI console.
THoughts? -eric On Apr 26, 2017, at 2:52 PM, Linux for blind general discussion wrote: > Tony and all, > I myself am completely opposed to a screen reader being locked into a kernel, > and have been for many years, for very good, technical, non-political > reasons. Text mode is exactly this: text mode. The layout of the entire > screen is available as plain text and some other character codes that affect > colors and other things, all of which are easy to interpret by a userspace > screen reader. This is the nature of the beast on all operating systems, no > matter the kernel. The screen reader *must* be fully in userspace, and must > be modular enough to handle slightly different input/output interfaces, > because that makes it portable to things like BSD, GNU/Herd or any other new > OS that may come alon, and all with at most the help of a small module that > knows how to read the text that is to be output to the screen, which can then > be sent out to a speech synthesizer, whether hardware or software, in an > equally modular way. Additionally, having a screen reader in userspace and > not bound to the kernel means that no one has to patch the kernel to accept > the screen reader, and screen reader developers don't have to answer to > kernel developers, kernel coding conventions or kernel release cycles in > order to continue development of the screen reader. Best of all, though a > single bug that goes uncaught in a kernel-bound screen reader has the > potential to crash the entire kernel, a userspace screen reader's bugs only > affect that application, and in the worst cases, the screen reader may need > to be restarted. No bug in a userspace screen reader will cause the report > you've put valuable hours into to get lost in cyberspace because a previously > hidden bug in the screen reader crashed the kernel before the report could be > saved. > > I did also mention the serial console as an alternative to a kernel-bound > screen reader. The whole reason I mentioned this at all is not just because I > can make a Raspberry Pi or even a less expensive computer act as a screen > reader, but because I not only receive kernel boot and shutdown messages, but > I receive boot loader messages as well, which the kernel is unable to > provide. This allows me to debug things that happen when the kernel fails to > boot. This can be caused by any number of kernel related problems, but can > also be caused by filesystem corruption and other things that the boot loader > can detect and report more easily than the kernel that is failing to boot. > The only time I would have a problem using the serial console method is if > the boot loader itself is either corrupt or has no serial i/o, and > thankfully, most do. > > You're absolutely right: YASR is not a viable userspace screen reader. In > fact, it's not a screen reader. Rather, it's a shell reader. There was in > fact a try at adding a separate program that could read the login screen, but > the overall nature of YASR makes it less than ideal, as you still have to run > a separate instance of YASR along with the shell in every terminal you want > to read. > > Finally, I will reiterate the fact that just because Speakup is not included > in a vendor or distro kernel does not indicate in any way that the vendor or > distro developers don't care about accessibility, any more than failing to > include the alsa front-end utilities would mean that a distro's developers > don't care about sound. Speakup is just one possible option, and because it > for a long time required a patched kernel, and now still requires staging to > be enabled in order for it to work, has technical limitations that force > distro developers and vendors to make hard choices about whether or not to > include such an unknown variable into the functionality of the kernel, which > by definition is to be a direct interface to the hardware rather than a way > to run userspace programs in kernel memory. Furthermore, there is a huge > difference between not caring at all about accessibility and not knowing how > best to handle it within the framework of an operating system, especially > with such technical limitations as a kernel-bound screen reader presents. I > have said this many times, and will continue to do so. Instead of complaining > about how little you think a developer or a group of developers cares about > accessibility, work toward fixing the inherent problems with the > accessibility tools and the technical limitations they present. At least give > distro developers enough information to try to help fix the problems rather > than just pissing and moaning on lists like this one when something you like > presents challenges to developers that they otherwise may not know the best > way to take on. > ~Kyle > > _______________________________________________ > Blinux-list mailing list > Blinux-list@redhat.com > https://www.redhat.com/mailman/listinfo/blinux-list _______________________________________________ Blinux-list mailing list Blinux-list@redhat.com https://www.redhat.com/mailman/listinfo/blinux-list
