[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Braille devices

/* I'm not on l-k at the moment, please Cc replies */

On Sat, Aug 19, 2000 at 09:48:03PM +0200, Simon Richter wrote:
> I've seen the request for braille device support during installation here
> on debian-devel for many times, and IMO the best approach would be to
> support these devices at kernel level. The reason for this is that a
> daemon approach would compromise system security, as some (luckily not too
> many) braille devices have special interface cards which require hardware
> access. Also, a daemon has to be started in order to be useful, so that
> you cannot see anything if the boot fails.
> Comments?

Agreed.  I have been pleading with anyone I came across willing to listen
for quite some time now to consider the idea of alternate console device
in the kernel for quite some time.  The same concept that applies to
multihead also applies here except that the alt console would allow for
some secondary I/O device to be used in addition to the primary one.

This would allow for custom alternate output devices such as braile
terminals or possibly speech synthesis drivers to be written as kernel
drivers and essentially always working.  It'd also allow such things as
use of an input device similar to the DARCI hardware (but much less
expensive) right in the kernel and as far as the console driver of the
kernel is concerned, anything sent and processed by the driver came
directly from the local keyboard.  Much more flexible than the serial
console driver is today.

For those who don't know, devices like the DARCI boxes are insanely
expensive - they cost more than twice the average machine of a person
reading this message.  What it does is simulate a keyboard.  It's
extremely flexible in its hardware implementation and extremely complex in
its configuration.  It can use all sorts of inputs from custom matrix
keyboards to a few switches to a surplus morse code key - use your
imagination a bit.  It outputs a standard keyboard signal.  In your choice
of PC, Mac, and I think also Sun formats.  It's purpose is adaptive input
for people who cannot use a traditional keyboard.  They may also have
alternative ways to simulate a mouse in newer models.  Most of these
special purpose devices can be connected to parallel or serial ports with
very little electronics no more complex than wiring up a playstation
controller for your favorite game emulator.

The possibilities for output have I think already begun to register.
Besides the obvious things like braille displays and speech, there are a
million different embedded applications for this.  Wearables anyone?

This is really the kind of thing that would not be very hard to do (I
hope) but it seems like it is also the kind of thing that must be agreed
upon because it will certainly affect a lot of things even if the effect
on them is not major.  Nonetheless, I feel it is something that should be
done because it is important to make Linux as accessable as possible.  It
should also be done because it'd be cool and open the door for a lot of
cool stuff.

(Ye personal-stake-in-this disclaimer: I am myself legally blind, but do
not read Braille or use a speech synthesizer.  I have enough vision that
the fact that my wterm has a font half an inch high on a 21" monitor I'm
less than 10" away from is fairly comfortable reading.  My vision is
20/310 and cannot be reasonably corrected at this time.  So yes I want to
see this done for other people with disabilities - but I'd never use such
a kernel device for that reason.  Not necessary.  I might use such a thing
to write a kernel driver for handling I/O for the wearable I've been
planning to build at some point, however.)

Joseph Carter <knghtbrd@debian.org>               GnuPG key 1024D/DCF9DAB3
Debian GNU/Linux (http://www.debian.org/)         20F6 2261 F185 7A3E 79FC
The QuakeForge Project (http://quakeforge.net/)   44F9 8FF7 D7A3 DCF9 DAB3

<Thoth_> Yeah, well that's why it's numbered 2.3.1... it's for those of us
         who miss NT-like uptimes

Reply to: