Hello,

Simon McVittie, le lun. 12 janv. 2026 12:33:50 +0000, a ecrit:
> Concretely, let's assume we have this cgroup hierarchy:
> 
> -.slice
> ├─user.slice
> │ └─user-1000.slice
> │   ├─[email protected] …
> │   │ └─ dbus-daemon --session, orca, gnome-terminal, etc.
> │   ├─session-55.scope (getty/login session on tty5)
> │   │ └─ text-mode shell
> │   └─session-22.scope (graphical session on tty2)
> │     └─ gdb-session-worker, gnome-session-binary, etc.
> 
> 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, in the
> same way that we copy DISPLAY and WAYLAND_DISPLAY from the graphical
> login session to the service manager: if I'm understanding correctly,
> he thinks that XDG_VTNR=2 has, or should have, semantics more like "this
> process belongs to a user who has a graphical login session on tty2,

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.

> even if this process is not necessarily part of that login session
> itself".

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
user-1000.slice, thus bringing the mess.

> 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.

> but not for members of [email protected],

It should be fine for those which are meant for the graphical session.

> I had assumed that it would be inappropriate/misleading for
> XDG_VTNR=2 to be copied into children of [email protected], which in
> principle are shared between session-22.scope and session-55.scope

It's wrong for session-55 indeed, since it already has its own
XDG_VTNR=5 since it's showing up on VT 5.

That's why at some point of the discussion I asked how to tell the
session that orca is to be started within session-22.scope. Actually to
my mind, all graphical-desktop-oriented services (e.g. icons in the tray
bar) should be started so.

Mantas Mikulėnas wrote:
> maybe orca should do whatever pulseaudio/pipewire already do to
> release devices

The orca case is very different because pulseaudio/pipewire only have
to release devices when switching to another VT not logged in as the
user. Here we want orca to release the braille output when switching to
another VT, even if it is logged in as the user.

Samuel
(Please Cc, I'm not subscribed)

Reply via email to