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