Sonar GNU/Linux merges with Vinux

[Linux for blind general discussion]

Kyle, it is just your opinion that a screen reader should not be in the 
kernel. And your reasoning for saying that amounts to that it shouldn't 
be in the kernel. You are making a meaningless distinction between a 
serial console and a screen reader. What difference does it make if 
there is a hardware speech synth attached to the serial port or a 
terminal emulator?

Well, clearly this is hopeless. Fortunately, it's not up to you anyway.

-- John Heim

On 04/27/2017 02:48 PM, Linux for blind general discussion wrote:
> The boot messages I receive from my computer before the kernel starts
> are piped out through a serial port automatically, and need no special
> configuration to display them. I just hooked up a uart cable to the
> header on one computer and the USB port on another and ran tinyserial's
> com utility on the USB connected machine before booting the other, only
> specifying /dev/ttyUSB0 as the serial device to listen to and 115200 as
> the baud rate. But those things at least appear to be fairly standard,
> and I can see no reason why having to run a single utility from a shell
> would preclude its use by anyone who needs it. I guess the difference
> may be that I run ARM computers here, although I was under the possibly
> incorrect impression that most newer machines, if they have serial ports
> at all, were supposed to make it that easy to pipe boot messages through
> them. So although serial console support is indeed in the kernel, it's
> in every kernel, and should be, as the serial console is an i/o device,
> whereas a screen reader should only be using that device if needed, and
> should not be locked into the kernel. The screen reader is an
> intermediary between the user and the traditional i/o devices; it is
> not, nor should it be, an i/o device. If someone does still need to be
> able to hear boot messages from the kernel while the initial ram disk is
> in use, said ram disk is perfect for running userspace applications
> early in most cases. And since many minimal distros run their live
> environments from RAM, adding sound drivers to the initial ram disk
> shouldn't cause too much pain, except on extreme low-memory systems,
> which in many cases won't have any sort of screen reader at all, as
> usually they only have a programmer interface these days, which is
> accessible via uart or some other means of connected communication.
>
> Incidentally, of all the ARM computers I've used, only the Raspberry Pi
> supports Speakup at all, and I have a strong preference for nearly any
> other, as the Pi just feels sluggish, possibly due to the i/o
> bottlenecks inherent in the design, and nearly all other computers even
> remotely in the same price range have noticeably better specs.
> Additionally, although I am able to install Arch in my sleep, and have
> even quite easily gotten Fedora 25 working on one of my computers by
> removing the installed Fedora kernel and copying over /boot from a
> working Arch system, the thought of compiling a kernel, especially since
> I would have to do it every time there is an update, is not at all
> appealing. Will I give up on the inexpensive and quite capable computers
> that I enjoy using or the distros I enjoy running on them? Absolutely
> not. Will I whine and complain because the vendors and their kernel
> developers "don't care about accessibility?" Most assuredly not, as I
> have other more viable options for getting speech when and where I need
> it. Or maybe I should whine and complain that Uthe uefi folks don't care
> about accessibility if it isn't as easy to get serial boot loader
> output. Again, no. Could I run a BSD on one of my ARM computers in the
> future? I can hope, as I do want to play with it some. Therefore, what I
> need most is a flexible and fully portable userspace screen reader that
> has access to kernel device interfaces when needed, but can be installed
> and will run on any machine, no matter the running kernel. Brltty almost
> fits that bill, but its screen reading functionality is nowhere near the
> quality of its braille feature set. Fenrir does have the dependency on
> Python, which is a rather large runtime for an initial ram disk or
> similar. So it may be that this SBL will be the best option, with a
> fallback serial console if I must debug using boot messages that come
> from the kernel, or from the boot loader, since I also see those quite
> easily with Uboot.
> ~Kyle
>
> _______________________________________________
> Blinux-list mailing list
> Blinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/blinux-list