The particular problem encounted was that Braille reader in question
directly used video memory to see what is on the screen. This requires
the computer to use only a single "page" of video memory, which DOS
normally does. Linux's scrollback feature defeats this, so some way of
turning off the scrollback was needed.
A simple patch to the console driver is possible (Change "int hardscroll = 1"
to "= 0") but applying a patch is not satisfactory for someone who cannot
read what is on the screen.
The solution to this, as I see it, has three parts. If anyone has any
suggestions on implementation, or useful criticism, I would very much like to
hear it. Any reasons why this shouldn't go into the kernel, or a better way
to do this would be greatly appreciated.
1. Change hardscroll from being a local (stack) variable to scrup() in
drivers/char/console.c to being a global variable that can thus be changed at
other places in the kernel. The default will still be 1.
2. Add an escape sequence (or perhaps an ioctl) to the console driver to
enable/disable scrollback. (This will require a bit of magic so that
disabling scrollback also moves the page offset back to the origin.)
3. Change the video mode selection code so that a bootup video mode of "-4",
or a particular key hit when a video mode is asked for (backspace?) will
serve the dual function of selecting a normal 80x25 video mode, and disabling
scrollback.
#3 is both the most complex and most important. The Braille reader in
question (Braillex ib80-piezo) can start tracking the screen directly from
bootup, so having scrollback disabled from the moment of bootup is important.
Making a new special video mode number allows any of a vast array of tools
(LILO, rdev, loadlin, etc.) to set this parameter, and thus it would not be
difficult to change this in a freshly aquired kernel image. In addition, if
any future changes are needed to allow Braille readers (or similar devices)
to work under Linux, hopefully they can be accomodated in the "-4" mode.
I should be skilled enough to add the "-4" video mode logic myself, along
with the changes to the console driver, but I'm not at all sure how easy it
will be for the setup.S code (where the video mode is selected) to affect the
hardscroll value. Should the hardscroll variable still be defined in
console.c, or should it be moved elsewhere? How can setup.S reference the
variable to change it? _Can it_?
Again, if anyone has anything to say on this topic, I'd love to hear it.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)