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? My concern is to pave the path for being able to run several graphical sessions. > 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? > 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? > 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. > 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. Samuel
