Hello, Simon McVittie, le lun. 12 janv. 2026 15:22:52 +0000, a ecrit: > On Mon, 12 Jan 2026 at 14:24:13 +0100, Samuel Thibault wrote: > > Simon McVittie, le lun. 12 janv. 2026 12:33:50 +0000, a ecrit: > > > Meanwhile, Samuel though that XDG_VTNR=2 should be copied from the > > > graphical login session into the `systemd --user` service manager, > > > dbus-daemon and similar processes so that orca would inherit it > > > > Yes. Provided that the process is related to the graphical session. > > Which is the case of anything that is started by the session for the > > graphical desktop, which is the case of Orca. > > But that isn't an option that is available to us: neither `systemd --user` nor > `dbus-daemon --session` have a way to distinguish between user-services that > are > related to the graphical session (e.g. orca, gnome-terminal), user-services > that are not (e.g. dirmngr, xdg-permission-store) and user-services that could > reasonably be argued either way (e.g. gvfs, pipewire).
That's the design issue that I see here. > > > I had always assumed that XDG_VTNR=2 should be set for members of > > > session-22.scope (often almost empty on a modern system) > > > > Being empty is the thing I see questionable there. > > That's a consequence of a design change in orca and/or gnome-session, > moving per-user services that are in some way associated with the graphical > login session from the login session itself into systemd units so that they > can be managed by `systemd --user`. Which is the move that made the design issue apparent. > There's only one activation environment[1] so we can either have XDG_VTNR be > inherited by every user-service, like DISPLAY, or by none of the > user-services, > like XDG_VTNR at the moment; The issue is the same for DISPLAY. I have read that systemd doesn't plan to support several DISPLAYs, but separating graphical services into a separate activation environment would allow to support several displays while seeing the graphical desktop services managed by systemd. > > As a matter of fact, orca *is*. It's just that apparently the startup of > > the graphical session (and thus orca) has moved from session-22.scope to > > [[email protected]], thus bringing the mess. > > (You said user-1000.slice, but I assume you meant [email protected], Yes. Samuel
