Hello, Simon McVittie, le lun. 05 janv. 2026 15:07:27 +0000, a ecrit: > 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)?
ATM, yes. It used not to be a user-service but simply started from gnome-session and such, and there was no issue. > 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 Yes, and its own output as well. It knows which VT is active since it's root. > - or, orca keeps track of which session it conceptually belongs to, > and silences itself when a different console session is active It cannot silence itself, it does not really have a way to know when a VT switch happens. > - 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 uids is not enough because the same user can run several graphical desktops on different VTs. > 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. Then the orca systemd service was wrongly defined. How can we make orca per-graphical session? > > 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. 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. > > > 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, 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. > 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>. I don't see how these variables could be wrong at the same time as the DISPLAY variable could be right. > > > 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). 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
