Hello Samuel, Replies inline.
On Wed, Jan 14, 2026, 05:51 Samuel Thibault <[email protected]> wrote: > Hello, > > Adrian Vovk, le mer. 14 janv. 2026 02:35:15 -0500, a ecrit: > > * The ideal immediate term solution here is for Orca to query the TTY of > the > > current logind session it's running on, and then pass that along. > > How does "current logind session" fit in this picture? > > -.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. > > Will that be session-22.scope? The session ID will be 22, yes My concern is to pave the path for being able to run several graphical > sessions. > If you mean multiple graphical sessions for one user, 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. 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. We've moved away from multiple graphical sessions on a single user for good reasons If you mean multiple graphical sessions in general, that works fine even today. It's just that for now each session runs on a distinct VT, but if VTs are compiled out then there's a other mechanism to switch between them (entirely logind managed) > 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 > If I recall correctly, the TTY handling is done by BrlTTY itself? > > Yes. But if the text console is entirely gone, BrlTTY doesn't need to do > any TTY handling any more, since there is nothing there anyway > When a client (Orca) requests TTY control over the display, it gives > the server a TTY number. Then the server monitors which TTY is active > and gives the corresponding client access to BrlAPI and suspends the > > others. > > Yes, that is it. But if the text console is entirely gone, there is no > notion of clients running on other TTYs. > > Or do you mean in case we have several graphical sessions? > I do mean the case where we have several graphical sessions. The user can still switch between them. > But they also work the same in other situations where TTYs > > don't: other seats (which I suppose BrlTTY has no way of supporting at > the > > moment) > > AIUI what is called "seat" is a keyboard+screen pair? Ideally the > braille device would be included in it. But several braille devices on > the same system for several users is a situation I have really never > seen. > Yeah I agree it's a niche situation. It's entirely possible to include braille devices with a seat, but only if BrlTTY is running in the user session. Then, switching sessions is equivalent to unplugging the device as far as the programs inside of the session are concerned But sure, it's an edge case and I'm not sure how useful it is. Theoretically, it might be possible to pass a braille device over RDP? That might be the most practical use case for multi seat support in BrlTTY > 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. Best, Adrian
