brltty udev rules

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

brltty udev rules

Chris Brannon
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: brltty udev rules

Keith Wessel-3
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:[hidden email]]
Sent: Wednesday, February 12, 2014 2:07 AM
To: [hidden email]
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: brltty udev rules

Keith Wessel-3
In reply to this post by Chris Brannon
Of course, this might also be irrelevant for dinosaurs like my serial
PowerBraille as the udev rules will only help with USB and Bluetooth
displays, correct? For serial displays, best option is to just use init and
let brltty remain running, automatically detecting the presence/absence of
the display if I understand correctly. Or is there more to udev than I know
about here?

Keith


-----Original Message-----
From: Chris Brannon [mailto:[hidden email]]
Sent: Wednesday, February 12, 2014 2:07 AM
To: [hidden email]
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: brltty udev rules

Chris Brannon
"Keith Wessel" <[hidden email]> writes:

> Of course, this might also be irrelevant for dinosaurs like my serial
> PowerBraille as the udev rules will only help with USB and Bluetooth
> displays, correct?

Correct.

Also, in response to your other message, I hadn't thought of the virtual
driver.  It isn't really a null driver, as it is supposed to communicate
over a socket with an application providing the virtual display.
But I suppose it could work for this purpose as well.

-- Chris

Loading...