[lkml]   [2000]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Braille devices

From: Simon Richter <>

> [CCed to linux-kernel, as IMO the best idea would be to implement this at
> kernel level]
> On Wed, 16 Aug 2000, VZW AUDIO/BRAILLE wrote:
> > Hi, I have on one pc the very great chance to use Debian 2.1 with a
> > hardware braille-display. But actually on another pc I'm suffering from
> > the refusal of my old braille display (not brltty supported) to let
> > me work under Deb. So on pc1 I've a great pleasure to work, on another
> > nothing more than frustration!
> [...]
> 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?

First, let me say that I'm actually the maintainer of BRLTTY
( and used it most everyday on Linux for
nearly six years now. I would like to take this opportunity to answer
some questions and kill some common myths that I keep encountering over
and over. All this rambling also applies to other packages similar to

Braille Display Support

BRLTTY is quite modular and actually support over 10 different brands of
braille display families. Adding another is just a matter of having the
protocol specification from the manufacturer (you know the classic
problem?) and someone to implement it. So the user space vs kernel space
argument is a non-issue for "my display isn't supported" statements.

The scarce braille displays requireing a special interface card are mostly
using firmware on the card that emulates a VGA text display, or that
retrieve data directly from the video memory of your VGA card, in order to
send it directly to the braille display thus not relying on software
support at all. In the case where kernel support is absolutely required,
only the raw low-level communication support must be in the kernel,
nothing more.

System Security

BRLTTY only requires access to /dev/vcsa0, /dev/tty0 and /dev/ttyS0. It
is intended to be used by the person at the console only and that person
usually has root access. If you don't want to run BRLTTY as root, you
just have to adjust permissions on the above devices.

Braille-Enabled Linux Installation

The fastest and easiest way to have Linux installed for a blind person
might still consist of a sighted person assisting the instalation up to
the activation of BRLTTY. Has anyone been able to install NT or W2K with
braille support during the OS installation anyway?

But... since Linux is also about freedom... Linux installation may even
be done with BRLTTY on bootdisks! I've installed many version of Red Hat
in the past without any sighted help and also got reports of success
stories for Slackware and Debian as well. The current development version
of BRLTTY contains a mini-howto on installation bootdisks hacking. I
encourage every interested distributors to have a look at it and maintain
a special bootdisk for braille-enabled Linux installation. I did it for
me, the recipee is available, but don't ask me to do it for you please.

Here again, the kernel solution isn't much of an advantage because you'll
typically have BRLTTY reside on an initial ramdisk (initrd) which contents
is executed before any kind of installation procedure. When the loading
of the initrd fails, it'll most probably be the case for the kernel as
well, and the blind person will remain clueless either ways. The "in the
kernel approach" doesn't bring an advantage worth its cost.

Since BRLTTY uses /dev/vcsa0, all kernel messages are available from the
console's scrollback function. Even the BIOS boot messages can be
consulted that way!


BRLTTY is a daemon simply because its job can be done outside the kernel.
It has been like that since 1995 and you know what? the first old version
from 1995 still can run unmodified on a 2.4.x kernel. So please always
look at what can be done in user space before advocating kernel solutions.
Putting this into the kernel would simply be a maintenance overhead.

My pay job consists of kernel hacking and I also maintain kernel support
for the StrongARM SA1100 in my free time. Therefore I'm quite familiar
with it and don't think adaptive applications belongs there. Some will
argue that Speakup is in kernel space but speech is a different matter
than braille, and I'm still not convinced anyway.

As a sidenote, people used to their good old DOS TSR for their
braille/speech hardware could have a look at DOSgate
( It lets you access the Linux
console transparently through a dosemu session using your DOS adaptation
tools. This might be an alternative to the lack of native Linux support
for some hardware... or lack of good enough Linux screen reader package
for one's taste.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:37    [W:0.048 / U:0.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site