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
