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

Reply via email to