On Wed, Jan 14, 2026, 11:41 Samuel Thibault <[email protected]> wrote:
> Adrian Vovk, le mer. 14 janv. 2026 10:23:59 -0500, a ecrit: > > On Wed, Jan 14, 2026, 05:51 Samuel Thibault <[1][email protected]> > wrote: > > > > > My concern is to pave the path for being able to run several graphical > > > sessions. > > > > If you mean multiple graphical sessions for one user, > > Yes, that's what I mean. > > > that's not actually something that can happen. For one, systemd > > explicitly doesn't support this situation. And for two, it's broken > > in a pile of other ways. Imagine if you have two copies of pipewire > > running and trying to overwrite each other's files. > > Why should I have two copies of pipewire? It is not related to the > graphical session and should remain at the root of the user session. > > Thing like tray icons, however, would be related to the graphical session and need to be kept separate, yes. > > > Or, conversely, if you had one pipewire running to serve two distinct > sessions, > > and sharing things like volume level that aren't necessarily supposed to > be > > shared. > > Why should they not be shared? Really, I don't see the relation between > pipewire and a graphical session. Tray icons have the same problem. You either run two copies and they conflict with each other (i.e. by trying to write over each other's config files), or you run one copy and have them not work right in one of the sessions. This applies to any session service. Dconf. gnome-settings-daemon. Etc Pipewire is related to the graphical session because it's tied to a seat. Running multiple graphical sessions at once allows you to run on different seats simultaneously. Which does not work when you're doing that as a user, because audio devices are tied to seats. One of the bugs fixed in GDM when we stopped running more than one session per user is that someone trying to log in via RDP could try to adjust the volume of the screen reader, and that would adjust the volume on all seats at once. Including the physical seat and all other RDP sessions. Imagine a school computer lab where you remote into a system. You might turn up the volume on your session because you have relatively quiet headphones, and blow out someone's eardrums who might be using more sensitive headphones in another session > We've moved away from multiple graphical sessions on a single user for > good reasons > > That is really not clear to me. > It's an architectural decision that was made over a decade ago, and trying to reverse course will break desktop environments. And, frankly, there really isn't much benefit. Not even sure why we're having this discussion. Very few people have a usecase that involves running two desktop environments simultaneously. And you can still do that, as long as they're not running under the same user. > > > Note that not all sessions are attached to a TTY - Orca will need > > > > to handle that too. > > > > > > > > * Orca should not continue relying on the existence of XDG_VTNR in > the long > > > > term. There have been ongoing experiments for years now to have > desktop Linux > > > > function with the entire VT subsystem disabled. This means that > XDG_VTNR would > > > > be empty because the concept of a VT wouldn't exist anymore on these > systems. > > > > > > In such as case, are ctrl-alt-f[1-6] not doing anything, I mean no text > > > console any more? > > > > These buttons won't switch between text consoles anymore, correct. But > they > > will still switch between logind sessions. And the solutions that > emulate the > > text console in userspace integrate with this, as far as I understand > > How is the switch happening, kernel-side? How are the switches of > keyboard input and such managed? > Logind manages it. It takes away access to the hardware (including access to KMS, keyboards, mice, audio devices, and any other hardware belonging to the seat) and gives it to the other session There's a level of collaboration between the session (i.e. Mutter) and logind. Ultimately logind enforces things with the kernel (i.e. by revoking the file descriptors it hands to sessions) but clients are expected to listen to logind's signalling and voluntarily give up control over the hardware as well if they don't want to be surprised by a suddenly inert fd. > Theoretically, it might be possible to pass a braille device over > > RDP? > > Yes, and this has been requested, just not implemented so far. > > > That might be the most practical use case for multi seat support in > > BrlTTY > > I don't see the relation between RDP and multi seat. I mean, I > understand that with RDP you'll have a user session that is unrelated to > the physical devices of the system. But that's fine, we don't care, just > like that RDP session doesn't care about the physical keyboard and > screen of the system. It's the RDP client that will transmit them and > get them integrated into another system, in a normal graphical session Each remote-login RDP session is its own (anonymous) seat. The seat doesn't have any hardware plugged in (so Mutter runs "headless") but it's still a seat > > Unfortunately, due to the way VTs work BrlTTY would need to support > both > > VTs > > > and logind sessions. There's no session running on a VT at the > login > > prompt. > > > But once the login happens, a session appears and "takes over" the > VT. > > This > > > edge case causes endless problems, especially for accessibility as > I'm > > sure you > > > well know, and fixing it is one of the goals of ridding the system > of VTs > > > entirely. > > > > I don't understand how getting rid of VTs will fix something? If that > > means removing the text console entirely, well, sure, there is > nothing > > to make accessible any more, so it drops the question. > > > > Yes exactly. It removes the weird state of "text console that needs to be > > accessible but has no services running". If each text console needs to > have a > > logind session attached, that could mean that we have a functional Orca > screen > > reader on each "text mode" console. And per-user audio daemons will work > > correctly. And so on. > > Except that *none* of the existing terminals (be they x-xterms, wayland-terms or fb-terms) are accessible at all with Orca except the libvte-based ones. > > So, no, it doesn't solve the problem. It drops the problem by dropping the sheer possibility of the use-case > Sounds like a problem of those terminal emulators, and they'd be inaccessible in the full fat desktop session too. If those desktop environments / terminal emulators don't have functional accessibility that's a problem for those desktops / apps to fix. It's perfectly possible to use libvte to render the "text mode" terminal when CONFIG_VT=n. It's not like the feature is gone entirely, it's just implemented completely differently Best, Adrian >
