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
