Personally I'd say that the semantics of XDG_VTNR follow DISPLAY if a graphical session is active. So even though *originally* [email protected] as a whole was "detached" from any session, it later had to learn DISPLAY and WAYLAND_DISPLAY out of necessity (for D-Bus systemd-based service activation, and all that) – which in effect now already causes *all* user services (whether intended to be headless or not) to become temporarily attached to a display whenever one is present – so I think it's equally safe to import XDG_VTNR (as long as it is un-imported at the end of the session, like how AFAIK gnome-session removes DISPLAY and such.)
Though maybe orca should do whatever pulseaudio/pipewire already do to release devices (I think pulseaudio queries systemd-logind?) Not sure. On Mon, Jan 12, 2026 at 2:33 PM Simon McVittie <[email protected]> wrote: > On Mon, 12 Jan 2026 at 00:11:44 +0100, Elias Oltmanns wrote: > > Developers on the Orca list have told me that Orca evaluates the > > environment variable XDG_VTNR in order to figure out whether it can and > > should restrict itself to a certain virtual terminal as far as driving > > the braille device is concerned. Just like most of the other GNOME > > components, Orca is started as a systemd user service nowadays. So the > > question is: how can and should XDG_VTNR be set to the correct value in > > the environment of Orca? > > We've had a similar issue reported in Debian testing/unstable as > <https://bugs.debian.org/1124600>, for essentially the same reason. In > Debian, the orca maintainer proposed changing the dbus package so that > X11 session setup (Xsession.d) would do > > dbus-update-activation-environment --verbose --systemd XDG_VTNR > > (similar to `systemctl set-environment XDG_VTNR=$XDG_VTNR` in systemd > world), > but as Debian's dbus maintainer I queried whether that was really correct, > because it contradicts my understanding of how XDG_VTNR is meant to work. > > Is there a specification for what XDG_VTNR means, which components may > rely on it, and how/where it ought to be set? > > https://systemd.io/WRITING_DISPLAY_MANAGERS/ is the closest thing > to a specification that I could find, and it tells display manager > implementors that they should set XDG_VTNR, but it doesn't give any > guidance for consumers of that variable, or for other session infra such > as dbus-daemon/dbus-broker. > > Concretely, let's assume we have this cgroup hierarchy: > > -.slice > ├─user.slice > │ └─user-1000.slice > │ ├─[email protected] … > │ │ └─ dbus-daemon --session, orca, gnome-terminal, etc. > │ ├─session-55.scope (getty/login session on tty5) > │ │ └─ text-mode shell > │ └─session-22.scope (graphical session on tty2) > │ └─ gdb-session-worker, gnome-session-binary, etc. > > If I understand the design correctly, in this scenario we want Orca > to drive the Braille device for as long as tty2 is in the foreground; > but when tty5 is in the foreground, we want Orca to get out of the way > and instead allow the tty console to operate the Braille device. > > The disagreement between me and Samuel on the Debian bug can be > summarized as: > > I had always assumed that XDG_VTNR=2 should be set for members of > session-22.scope (often almost empty on a modern system) but not for > members of [email protected], because I thought that XDG_VTNR=2 had the > semantics of "this process is part of a login session that is running > on tty2". I had assumed that it would be inappropriate/misleading for > XDG_VTNR=2 to be copied into children of [email protected], which in > principle are shared between session-22.scope and session-55.scope > (even though some of those children, and in particular GUIs like Orca, > are more closely related to the graphical login session than to the tty > login session). > > 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, in the > same way that we copy DISPLAY and WAYLAND_DISPLAY from the graphical > login session to the service manager: if I'm understanding correctly, > he thinks that XDG_VTNR=2 has, or should have, semantics more like "this > process belongs to a user who has a graphical login session on tty2, even > if this process is not necessarily part of that login session itself". > > Which of us is understanding the semantics of XDG_VTNR correctly? Or if > neither of us, what is the real meaning? > > > Developers on the Orca list have told me that Orca evaluates the > > environment variable XDG_VTNR in order to figure out whether it can and > > should restrict itself to a certain virtual terminal as far as driving > > the braille device is concerned. > > I suggested on the Debian bug that Orca could do the libsystemd or D-Bus > equivalent of: > > $ loginctl show-user --property=Display $(id -nu) > Display=22 > $ loginctl show-session --property=TTY 22 > TTY=tty2 > > to ask the question "which of my one-or-more login sessions is > graphical?" followed by "which tty is that login graphical session on?" - > which indirectly answers the question of which tty the X11 or Wayland > display belongs to. In libsystemd I believe this would look something > like: > > int res; > g_autofree char *login_session_id = NULL; > g_autofree char *tty = NULL; > if ((res = sd_uid_get_display(getuid(), &login_session_id)) < 0) { > ... error ... > } > if ((res = sd_session_get_tty(login_session_id, &tty)) < 0) { > ... error ... > } > ... use tty ... > > (But clearly this is more complicated than querying one environment > variable.) > > smcv >
