Control: retitle -1 dbus: brltty cannot correlate orca user-service with
current VT
Control: affects -1 + brltty
On Mon, 05 Jan 2026 at 12:57:22 +0100, Samuel Thibault wrote:
Simon McVittie, le lun. 05 janv. 2026 11:17:10 +0000, a ecrit:
Is there a solution-neutral problem statement for these Braille output
issues?
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.
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.
Simon McVittie, le lun. 05 janv. 2026 11:15:01 +0000, a ecrit:
Is there a specification for how XDG_VTNR is meant to work?
https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html#%24XDG_VTNR
documents it.
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.
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?
Yes.
That's what I thought, but then this contradicts the next thing you said:
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.
Yes, exactly.
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>.
How does this work in other distros?
Other distros are probably using xorg/50-systemd-user.sh which requires
the same.
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
