Hello, Simon McVittie, le lun. 05 janv. 2026 11:15:01 +0000, a ecrit: > 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?
https://www.freedesktop.org/software/systemd/man/latest/pam_systemd.html#%24XDG_VTNR documents it. > 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. > 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. > 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? 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. > 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 That looks uselessly complex compared to XDG_VTNR which has been there since very long. > How does this work in other distros? 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: > 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. > > 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. Samuel
