RE: [gentoo-accessibility] brltty udev rules

["Keith Wessel" <keith@wessel.com>]

I don't use brltty for speech, but it seems you could disable braille and
just have speech using the virtual vraille driver (code vr). Of course, you
could also set it to a port and display that you don't have, but that would
give some ugly log warnings and is more of a hack than a solution IMHO.

I do like the udev idea; not sure why it never occurred to me instead of
using init. I assume this will work with systemd's version of udev, too?
Will try that once I finally reboot and try the system start script.

Keith


-----Original Message-----
From: Chris Brannon [mailto:teiresias@gentoo.org] 
Sent: Wednesday, February 12, 2014 2:07 AM
To: gentoo-accessibility@lists.gentoo.org
Subject: [gentoo-accessibility] brltty udev rules

Here's a fragment of the brltty udev rules:

LABEL="brltty_add"
SYMLINK+="brltty/$env{BRLTTY_BRAILLE_DRIVER}-$env{BRLTTY_BRAILLE_DEVICE}"
RUN+="/bin/brltty -E -P$env{BRLTTY_PID_FILE}"
GOTO="brltty_end"

LABEL="brltty_remove"
RUN+="/bin/sh -c 'kill -TERM `cat $env{BRLTTY_PID_FILE}`'"
GOTO="brltty_end"

So basically, this starts *an instance* of brltty whenever a braille display
is connected and kills the corresponding instance when the display is
unplugged.
Yes, this seems quite reasonable.  It's plug-and-play, and I can see why
folks like that, even though I'm an old curmudgeon.
But if you're using those rules, you'd better not start the daemon at all
from your init system.  If you do, you've got a problem, because you'll have
two running daemons trying to communicate with the same display!
At least, that's what happens with the default configuration, because it
autodetects the braille driver.
Also, if you have a speech-driver setting in your /etc/brltty.conf, you'll
probably end up with two daemons trying to provide speech.  I haven't
verified this, however.

This is only a problem if you want to use brltty for both speech and
braille.  If you just want it for braille, then don't start it from the init
system.  Let udev start it automatically for you, and you're golden.  If you
want to use brltty for both speech and braille, you're going to have to work
around this somehow.

As far as I can tell, there's no way to select a "null" braille driver.
So if you want to use this udev autostart scheme, you don't have the option
of spawning a brltty that will only be used for speech.
In short, the udev scheme is incompatible with using brltty for both speech
and braille.

Probably your best bet is to override the udev rules.  First copy
/lib/udev/rules.d/70-brltty.rules to /etc/udev/rules.d/70-brltty.rules.
Edit /etc/udev/rules.d/70-brltty.rules, and delete the lines that contain
RUN+= Right now, there are just two of them:
RUN+="/bin/brltty -E -P$env{BRLTTY_PID_FILE}"
and
RUN+="/bin/sh -c 'kill -TERM `cat $env{BRLTTY_PID_FILE}`'"
You'll need to repeat this procedure every time you upgrade brltty, just to
keep your modified rules from getting out of sync with the rules from
/lib/udev/rules.d.
Yeah, overriding files in /lib or /usr/lib with files in /etc is fragile in
the face of updates, but that's the way udev does things...
Anyway, this disables autostarting of brltty from udev.

Now, someone please tell me that there's a better way to do this, and that
I'm seeing problems that do not exist.  I'd love to believe that I'm
delusional!

-- Chris