Bug#1124600: dbus: brltty cannot correlate orca user-service with current VT

[Simon McVittie]

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