[BRLTTY] Console open error on recent Arch Linux

[Dave Mielke]

[quoted lines by Aura Kelloniemi on 2025/09/29 at 23:02 +0300]

>1) It still reports "no screen".

No one else is having this problem. There's clearly something unique about your system and/or your brltty installation. I wouldn't mind having a direct look at it. If you'd like to allow me to do that then please contact me off-list to discuss.

>2)  Every time I connect my braille display using USB, it starts a
>    new BRLTTY instance. I cannot use BrlAPI applications with this instance.

Yes. Since the udev mechanism can start several instances, and since they can't all serve the same brlapi port, this would need special configuration. When I mentioned udev rules I was referring to the uinput and HID rules.

>3) It changes permissions of /dev/hidraw* and /dev/uinput so that BRLTTY can
>access these devices, but BRLTTY does not need access to these devices on my
>system.

Maybe not HID, but, yes, probably uinput. This has to do with the way the Linux screen driver works in order to implement the best possibel braille device keyboard support.

>I believe the problem is not solved by BRLTTY's udev rules, because these
>rules don't change permissions of the /dev/tty0 device which BRLTTY needs for
>accessing the console.

Then there's something fundamentally wrong with the way that brltty is being invoked. But, again, no one else seems to be having this problem and I have no guesses.

Maybe you could send a full debug log with -ldebug and -L/pth/to/logfile.

>Also I wonder whether there is a better way to give BRLTTY accewss to devices
>than changing the permissions of the device node. Changes to device
>permissions will last even if BRLTTY is stopped. In case system user IDs
>change (e.g. due to package removals/installs) it may be that some process
>unintentionally gains access to some devices.

I'm open to ideas. Also, just to be sure that no one misunderstands, the actual node permissions aren't changed. ACLs are added that grant access specifically to the brltty user.

There actually is another way but I don't want to use it. That way is to give brltty the CAP_FOWNER capability but that'd bypass all file system security for brltty. The mainframe we used way back in my university days ran a very cool university-developed operating system - MTS - which had a command to grant specific types of access to specific files for specific programs. Too bad modern systems don't have such a facility.

-- 
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   |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://mielke.cc/xmother.html (Letter from a Feminist ex-Mother)