Hello,

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.

Samuel

Control: tags -1 + moreinfo
Control: affects -1 + orca

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

Is there a solution-neutral problem statement for these Braille output
issues?

Thanks,
     smcv

Hello,

Simon McVittie, le lun. 05 janv. 2026 11:15:01 +0000, a ecrit:

https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html#%24XDG_VTNR
documents it.

Yes.

Yes, exactly.

The orca service, at least, is really tied to a graphical login
session.  So it needs the information for that session, be it DISPLAY,
WAYLAND_DISPLAY, or XDG_VTNR.

That looks uselessly complex compared to XDG_VTNR which has been there
since very long.

Other distros are probably using xorg/50-systemd-user.sh which requires
the same.

Orca getting started by activation is something quite new, not
necessarily picked up by distributions yet, so the issue has probably
just not surfaced yet.

Simon McVittie, le lun. 05 janv. 2026 11:17:10 +0000, a ecrit:

Orca is not the only producer of braille on the system. When the user
switches to another VT, the actual braille driver (brltty) needs to know
that the Orca output was meant only for its own VT and not the others.

Samuel

Control: retitle -1 dbus: brltty cannot correlate orca user-service with current VT
Control: affects -1 + brltty

Am I correct to think that orca is a user-service (a child of systemd --user
or dbus-daemon --session), while brltty is a system service (a child of
pid 1 or dbus-daemon --system)?

So during VT switching, one of these approaches is needed?

- brltty keeps track of potentially multiple orca instances, correlates
   them with the currently active console session, and silences text output
   from the others
- or, orca keeps track of which session it conceptually belongs to,
   and silences itself when a different console session is active
- or potentially a hybrid where brltty silences *uids* that differ from the
   active console session, but orca is responsible for silencing itself
   when the graphical session is not the active one

But if the same user is logged-in on more than one VT, then the Orca
instance is (conceptually) shared between all of those login sessions -
that's what it means to be a systemd user-service or a D-Bus session
service. That would suggest that it might be the user-session (uid) that
should matter, not individual login sessions.

That documents how libpam_systemd uses XDG_VTNR, but doesn't describe
how other components (like brltty and/or orca) are allowed/expected to
use it, or how the components that set and propagate it are expected to
set it.

 From codesearch, it looks as though the component that sets XDG_VTNR is
the display manager (gdm or similar), so this is "API" between multiple
components. https://systemd.io/WRITING_DISPLAY_MANAGERS/ is perhaps
closer to a specification, but doesn't really say anything about
how/whether brltty can rely on it. I couldn't see anything obvious in
https://specifications.freedesktop.org/ either.

That's what I thought, but then this contradicts the next thing you said:

For these services, XDG_VTNR can't be both unset, and also set to the VT
where the graphical session (if any) is running: we have to choose one
or the other. You're asking me to change that choice, and before doing
that, I want to be sure that I'm not undermining the way XDG_VTNR was
meant to work and regressing some other component that relies on
specific semantics for it.

gnome-session also specifically doesn't copy around the XDG_VTNR (and
some others) "as they might end up in the wrong session":
<https://sources.debian.org/src/gnome-session/49.2-3/gnome-session/gsm-util.c?hl=40#L40>.

If you mean the xorg/50-systemd-user.sh from src:systemd, that copies the
DISPLAY and XAUTHORITY (like dbus' 20dbus_xdg-runtime), but does not
copy XDG_VTNR (again, same as dbus' 20dbus_xdg-runtime).

     smcv

Hello,

Simon McVittie, le lun. 05 janv. 2026 15:07:27 +0000, a ecrit:

ATM, yes. It used not to be a user-service but simply started from
gnome-session and such, and there was no issue.

Yes, and its own output as well.

It knows which VT is active since it's root.

It cannot silence itself, it does not really have a way to know when a
VT switch happens.

uids is not enough because the same user can run several graphical
desktops on different VTs.

Then the orca systemd service was wrongly defined. How can we make orca
per-graphical session?

It's just all processes that show up on that VT which should have this
variable. In the X world, it's simply inherited from the X session
script.

The contradiction is not in what I wrote, but in what "a user service"
means. What orca needs is a service related to a graphical desktop. Not
a global service for all is text/ssh/graphical sessions.

Really, our need of XDG_VTNR is exactly like the DISPLAY variable.

Thus why I'm proposing to use exactly the same approach.

If what I propose is wrong, how can it be correct for DISPLAY?

That's where I see a contradiction.

I don't see how these variables could be wrong at the same time as the
DISPLAY variable could be right.

Yes, and again, I don't see why XDG_VTNR can't be copied there, for
exactly the same reason why DISPLAY is copied.

Samuel