Adrian Vovk, le mer. 14 janv. 2026 12:28:51 -0500, a ecrit: > On Wed, Jan 14, 2026, 11:41 Samuel Thibault <[1][email protected]> wrote: > > > > 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
So we just decided to stop being able to do concurrency, ok. > Pipewire is related to the graphical session because it's tied to a seat. Yes, to a seat, but not to a particular session which is graphical. It can be used just all the same in a text console etc. Which is very different from a tray icon which is meaning less on a text console, and clearly for a graphical session. > 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. Yes, it should be per-seat, sure. But that doesn't preclude from having several graphical sessions running concurrently on the same seat, and yes if I raise the volume in one, I'd expect it to raise on the other one. > > > 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. Ok, thanks for the explanation! > > > 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 Ok, but then it's unrelated to brltty being able to achieve multi-seat. I mean, the real brltty that the RDP session will be talking to is the brltty running on the client side. On the server, there won't even be a brltty, but only a brlapi relay to the brltty running on the client side, and the RDP session would have a BRLAPI_HOST environment variable to know where to connect to get its braille through. > > > > > 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. Yes, but CONFIG_VT=n is pulling the plug of the only existing alternative to libvte. > 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 Libvte itself is not without its bugs. We have some that have been waiting for a decade now, which make serious user work really problematic. And no, it's not out of lack of patches proposals. So, no, CONFIG_VT=n is not bringing progress, but regression, here. Samuel
