[quoted lines by Aura Kelloniemi on 2020/08/23 at 01:21 +0300] >Could you recommend me an easy solution which allows me to install and run >BRLTTY with reduced privileges, and then return to the full privileges version >(blindly) when it shows "No screen".
I think it's better to do this kind of testing using a text console so that you don't have the added complexity of knowing which brltty instance Orca is connecting to. You don't need to install an experimental brltty in order to test it. Instead, just build it and then run what you just built by using the run-brltty script in the top-level of the source tree. Even easier is to write a small wrapper script for that which specifies all the desired options and then run that wrapper with no opsions. The options you give to run-brltty are exactly those that you'd give to brltty itself. >I have a spare display available that I can use, Good. Specify the options for it, e.g. driver and device, when invoking run-brltty. >but I probably cannot have multiple BRLTTYversions installed at the same time, >because the systemd files need to be in place. there are ways, but it's so much easier to test without installing by using the run-brltty script. > > i'm wondering if you may have a mixture of older and newer systemd > > units/files. > >Should not be. Sure, but one must never make assumptions, i.e. one must check everything, when things don't seem to be working right. Trusting oneself should be ones own worst enemy. Could you please send me all of your systemd-related files so that I can have a look at them? >I had brltty.path, [email protected], [email protected], udev rules, and sysusers and >tmpfiles configuration files. What's the path to your installed sysusers file for brltty? >I also had the brltty user and groups defined, What's the output of the commande: id brltty >but the problem can be there, if systemd did not generate them properly. That's one of the things that we need to investigate. >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: continuing to execute as >the invoking user: brltty So it isn't actually being started as root. This makes sense because that's what systemd is being told to do. Let's first test with you invoking run-brltty as root, though, to verify that the problem in somewhere within what systemd - not brltty - is doing. >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: capability not >permitted: cap_sys_module >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: capability not >permitted: cap_setgid It looks like systemd didn't add the capabilities to brltty's process. >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: path not group readable: >/dev/uinput >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: path not group writable: >/dev/uinput This is a known issue and we provide a udev rule to correct for it. Please also send a copy of your brltty udev rules file for inspection. >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: group not joined: >977(brlapi) I'm guessing that you have /etc/brlapi.key, and that it's owned by the brlapi group. That, by the way, is exactly hw I do it. >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: group not joined: >987(uucp) This one is odd. Are your serial devices, e.g. ttyS0, owned by the uccp group rather than by the dialout group? Maybe there are two (or more) "standards" for serial device ownership. >elo 19 10:15:32 solaria systemd-wrapper[929]: brltty: cannot create directory: >/run/brltty: Permission denied This problem needs to be fixed. For now, maybe you should just manually create the /run/brltty directory. The solution will probably be for [email protected] to use ExecPre to create it. >elo 19 10:15:32 solaria systemd[1]: [email protected]: Can't open PID file /run/brltty/brltty--dev-bus-usb-003-004.pid (yet?) after start: Operation not permitted This is a symptom of /run/brltty/ not having been created. >BRLTTY fails to open /dev/tty1 (Permission denied) I guess that's what "Lupa evätty" means. >even though it manages to join the group tty (/dev/tty1 is owned by my user >and has group tty). What are its permissions? Tle whole ls -l output line would be interesting to see. In any event, this shouldn't be an issue if brltty is running as root. >The only group missing is dialout, because I already removed the systemd files >shipped with brltty (to get it running as root). That wouldn't remove brltty believing that it needs access to it. >dialout should not be needed for screen access though. It isn't - it's for serial device access. On your system, however, it seems that the uucp group might be used for this. > > For now, disable brltty's udev rules. > >I will, and I probably never need them, since I always use one display, and I >want it to be managed by a single BRLTTY instance regardless of whether I'm >using bluetooth or USB. That, however, may be why you aren't benefitting from the rule to fix the /dev/uinput access problem. >This is an excerpt from /lib/systemd/system/systemd-udev-settle.service: ># This service can dynamically be pulled-in by legacy services which ># cannot reliably cope with dynamic device configurations, and wrongfully ># expect a populated /dev during bootup. Well, brltty can. It does so by retrying, which can mean that it'll connect to the device somewhat later than as soon as possible. That's why it depends on that service - so that it'll start as soon as udev is ready. -- 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: [email protected] | 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: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
