Control: tags -1 + moreinfo
Control: affects -1 + orca
On Sat, 03 Jan 2026 at 18:24:53 +0100, Samuel Thibault wrote:
We are having braille output issues because the orca screen reader does
not know which Linux virtual console it is running on. The dbus session
should be pasing it the XDG_VTNR for it to know this, as the attached
patch does.
Is there a specification for how XDG_VTNR is meant to work? (cc'ing the
systemd maintainers because if anyone knows, it would be them)
At the moment, XDG_VTNR is specifically *not* added to the activation
environment even if you have the deprecated dbus-x11 package (and its
/etc/X11/Xsession.d/95dbus_update-activation-env) installed, on the
basis that it's a fact about individual login sessions rather than a
fact about the overall user-session. The same is true for XDG_SEAT,
XDG_SEAT_PATH, XDG_SESSION_ID and XDG_SESSION_PATH.
The terminology is that if uid 1000 is logged in via gdm on tty2, via
getty/login on tty6 and via ssh, then we say uid 1000 has three login
sessions (tty2, tty6 and the ssh session), but only one user-session
(therefore only one `systemd --user`, and if using dbus-user-session,
only one `dbus-daemon --session` or its dbus-broker equivalent).
I had the impression that in this scenario, XDG_VTNR should be 2 for
processes belonging to the graphical login session on tty2, 6 for
processes belonging to the text-mode login session on tty6, unset for
processes in the ssh login session, and also unset for services started
by `systemd --user` that are (at least conceptually) shared between all
of those login sessions. Is that correct?
What you're proposing seems to be that the XDG_VTNR of a graphical login
session should be copied to the environment of services started by
`systemd --user`, the same way we copy around DISPLAY and
WAYLAND_DISPLAY. But that doesn't really seem right to me, because
conceptually those services are shared by all VTs rather than belonging
to a single VT?
If Orca or a Braille output mechanism wants to find the user's graphical
session (if any) and what VT it is on, another way would be for it to
ask systemd-logind using D-Bus messages: the equivalent of
$ loginctl show-user --property=Display $(id -nu)
Display=4
$ loginctl show-session --property=TTY 4
TTY=tty2
which might be an alternative to using that environment variable?
How does this work in other distros?
smcv