Hello all, I have some thoughts to add, in no particular order.
* Running Orca as part of the systemd --user session is unequivocally the right thing to do, and going back to the way it was before is no longer possible anyway. The code that used to do that is gone and there's no easy way to bring it back. * Having more than one activation environment is interesting. OpenRC is experimenting with a model where services declare what variables they want to pull in from their dependencies. I think a separation between GUI and non-GUI activation environments might be more practical. But I don't think this is the underlying source of the problem * The ideal immediate term solution here is for Orca to query the TTY of the current logind session it's running on, and then pass that along. Note that not all sessions are attached to a TTY - Orca will need to handle that too. * Orca should not continue relying on the existence of XDG_VTNR in the long term. There have been ongoing experiments for years now to have desktop Linux function with the entire VT subsystem disabled. This means that XDG_VTNR would be empty because the concept of a VT wouldn't exist anymore on these systems. Most of the stack has been ported to work in this environment, so while I won't say CONFIG_VT=n is imminent, it's definitely on the horizon If I recall correctly, the TTY handling is done by BrlTTY itself? When a client (Orca) requests TTY control over the display, it gives the server a TTY number. Then the server monitors which TTY is active and gives the corresponding client access to BrlAPI and suspends the others. My memory is a tad fuzzy about this so please correct me if I'm wrong What should happen is that BrlTTY needs to expand its definition of TTY to also include logind sessions. On seat0 of a TTY-full system, logind sessions correspond to TTYs. But they also work the same in other situations where TTYs don't: other seats (which I suppose BrlTTY has no way of supporting at the moment) and VT-less systems included. And it's a nicer API to boot. Unfortunately, due to the way VTs work BrlTTY would need to support both VTs and logind sessions. There's no session running on a VT at the login prompt. But once the login happens, a session appears and "takes over" the VT. This edge case causes endless problems, especially for accessibility as I'm sure you well know, and fixing it is one of the goals of ridding the system of VTs entirely. But since we'll have VTs for years to come, BrlTTY will need to handle all three cases: VT with no session, session with no VT, and session with VT But ultimately: Orca should be able to tell BrlTTY "I'm running on session 22" and BrlTTY should monitor session 22 through logind. That's the only way for this bug to not return when distros start to flip CONFIG_VT=n. I hope that's useful guidance Best, Adrian On Tue, Jan 13, 2026, 16:49 Elias Oltmanns <[email protected]> wrote: > Hi Simon, > > On 2026-01-12 at 16:44:56 (+0100), Samuel Thibault <[email protected]> > wrote: > > Hello, > > Simon McVittie, le lun. 12 janv. 2026 15:22:52 +0000, a ecrit: > >> On Mon, 12 Jan 2026 at 14:24:13 +0100, Samuel Thibault wrote: > >> > Simon McVittie, le lun. 12 janv. 2026 12:33:50 +0000, a ecrit: > >> > > Meanwhile, Samuel though that XDG_VTNR=2 should be copied from the > >> > > graphical login session into the `systemd --user` service manager, > >> > > dbus-daemon and similar processes so that orca would inherit it > >> > > >> > Yes. Provided that the process is related to the graphical session. > >> > Which is the case of anything that is started by the session for the > >> > graphical desktop, which is the case of Orca. > >> > >> But that isn't an option that is available to us: neither `systemd > --user` nor > >> `dbus-daemon --session` have a way to distinguish between user-services > that are > >> related to the graphical session (e.g. orca, gnome-terminal), > user-services > >> that are not (e.g. dirmngr, xdg-permission-store) and user-services > that could > >> reasonably be argued either way (e.g. gvfs, pipewire). > > > > That's the design issue that I see here. > > > >> > > I had always assumed that XDG_VTNR=2 should be set for members of > >> > > session-22.scope (often almost empty on a modern system) > >> > > >> > Being empty is the thing I see questionable there. > >> > >> That's a consequence of a design change in orca and/or gnome-session, > >> moving per-user services that are in some way associated with the > graphical > >> login session from the login session itself into systemd units so that > they > >> can be managed by `systemd --user`. > > > > Which is the move that made the design issue apparent. > > > >> There's only one activation environment[1] so we can either have > XDG_VTNR be > >> inherited by every user-service, like DISPLAY, or by none of the > user-services, > >> like XDG_VTNR at the moment; > > > > The issue is the same for DISPLAY. I have read that systemd doesn't plan > > to support several DISPLAYs, but separating graphical services into a > > separate activation environment would allow to support several displays > > while seeing the graphical desktop services managed by systemd. > > Please forgive me when I state the obvious or correct me if I'm wrong. > Samuel's point about DISPLAY seems very compelling to me. It may seem > unintuitive to have DISPLAY in the activation environment, thus making > it available to processes that really are not GUI related at all. Still, > it has been decided to do so which imposes restrictions such as having > only one DISPLAY, but as things stand right now, all GNOME users would > be in deep trouble if DISPLAY suddenly was not available in the > activation environment. Similarly, the single activation environment may > not be the perfect match for XDG_VTNR, but without it being included, > GNOME users with braille devices are in trouble right now. Besides, I > fail to see the downside of including XDG_VTNR as long as DISPLAY is > included but this may just be due to my limited knowledge about the use > and scope of XDG_VTNR. > > There seem to be at least three options how to proceed: > 1. Communicate XDG_VTNR via the one activation environment we have in > some appropriate way. > 2. Discuss with the GNOME developers whether the move towords systemd > units really is the way to go for Orca and possibly other processes > as well. > 3. A discussion between you guys and perhaps the GNOME developers > whether multiple activation environments actually do merit some > effort as Samuel suggested. > > Do you have any thoughts on that? I get that this issue may be not quite > straight forward but the situation really is rather awkward for braille > users and will affect more people as distros migrate to GNOME 49. > > Thanks for your input so far. > > Best, > > Elias > >
