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. > We've moved away from multiple graphical sessions on a single user for > good reasons That is really not clear to me. > > > 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? > 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. > > 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. Samuel
