Sonar GNU/Linux merges with Vinux

Thu Apr 27 00:20:59 UTC 2017

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list