[BRLTTY] Udev being fussy

[Keith Wessel]

Thanks, Dave.

First, to clarify as I think I confused you when I mentioned Centos. This is
my home system that I'm working with which, as I mentioned in my first
message, is running Gentoo. Not sure why the latest Gentoo ebuild, stable or
unstable, is way back at 5.2. But The Centos system isn't involved here. I
only mentioned it because it's at work and is running my manually built
brltty 5.6 RPMs. I've seen your system and udev handywork over there. This
display hasn't been connected to that computer yet, but I have no doubt
things will go smoothly when I plug the display in to that one when I'm next
in the office. (The office is 600 miles away from me, BTW, and I wont' be
upt here until April.)

But what I did do just now was to ssh into that Centos system and grab the
/lib/udev/brltty-wrapper from that Centos box and put it on the Gentoo box
here at home. I then modified the run and remove sections of my
70-brltty.rules to run the exact commands you have in 90-brltty.rules in the
Centos RPMs which, as you stated, use the wrapper that execs brltty. I was
sure that would do it. Sadly, no. After 3 minutes or so, brltty was killed
again. Log for udevd was identical. That shouldn't have happened. I need to
try it again to see if, for some reason, the wrapper doesn't terminate. But
I don't know why it wouldn't unless I modified the rules wrong and the
wrapper wasn't being used at all.

So, I moved on to your easier suggestion and renamed the 70-brltty.rules to
70-brltty.rules.old. I then restarted system-udevd to make sure it wasn't
caching the rules. I started brltty.service with systemctl start brltty, let
things start up, then unplugged the braille display. Brltty played it's
disconnect beep immediately. But when I plugged the display back in, no
luck. It didn't re-initialize. I should add that when this happens, the
console also hangs. The only way I can restart brltty at this point is to
ssh into the Linux system from my Windows computer and stop then restart the
brltty system service.

I suppose it's possible that the udev rules were still somehow in the
picture, but I'm not sure how. I would have rebooted the computer to see if
that helped, but this system hosts the music files that are currently
streaming in my son's bedroom upstairs while he's sleeping, and... Well, I
think you can see why I didn't mess with that. :)

Your suggestions made sense, but I'm obviously doing something wrong or
overlooking something more complex. I'll try a reboot tomorrow to see if
that makes a difference.

In the meantime, I'm tempted to build brltty from source to get a newer
version along with the udev and system improvements you have in 5.6. Perhaps
it's time to ask the folks over on the Gentoo-accessibility list if there's
an easier way to get a newer version.

Any other thoughts appreciated.

Keith


-----Original Message-----
From: BRLTTY <brltty-bounces at brltty.app> On Behalf Of Dave Mielke
Sent: Friday, February 1, 2019 4:07 PM
To: Informal discussion between users and developers of BRLTTY.
<brltty at brltty.app>
Subject: Re: [BRLTTY] Udev being fussy

[quoted lines by Keith Wessel on 2019/02/01 at 14:57 -0600]

>Am I correct that I should either have brltty.service running or let 
>system-udevd start and stop brltty, but not both?

Udev will only work by itself if you use brltty's udev wrapper script as
brltty does keep running.

Your udev rules file is probably old as it doesn't contain the bits
necessary to interact with systemd. The simplest thing for you to do,
therefore, is to disable the udev rules (my method is to rename .rules to
.rules.off) and to enable the systemd service.

The systemd service you have looks very stripped down so maybe RedHat
decided not to use ours. The latest version of all our stuff (udev and
systemd) may look a little complex but lets multiple managede brltty
processes run at the same time. USB-connected braille devices are managed by
the udev rules, and, for non-USB, you can have multiple brltty.conf files
(named
brltty_instance.conf) managed by brltty at instance.path units. If you'd like
that flexibility then I can help you get it set up.

>I thought that brltty, itself, had some polling built into it for 
>reconnects.

Yes, it does. That's why disabling the udev rules and starting the systemd
service will work for you if you only need one brltty instance.

>Seems like running brltty.service at start-up with a display of auto 
>and a device of usb: should be as good as anything for detecting
reconnects.

Yes, but only if you disable the udev rules so they won't mess with yuu.

>The udev rules from /lib/udev/rules.d/70-brltty.rules is running 
>/bin/brltty directly, not a wrapper.

That'd be why udev is killing brltty. You could add the wrapper and then
modify the rules to use it. If you go that route then you'd need to disable
the systemd service.

--
I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
Dave Mielke            | 2213 Fox Crescent | WebHome: http://Mielke.cc/
EMail: Dave at Mielke.cc  | Ottawa, Ontario   | Twitter: @Dave_Mielke
Phone: +1 613 726 0014 | Canada  K2A 1H7   |
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY at brltty.app For general
information, go to: http://brltty.app/mailman/listinfo/brltty