PiP protocol addition...!?

Posted Oct 23, 2025 15:27 UTC (Thu) by daenzer (subscriber, #7050)
In reply to: PiP protocol addition...!? by kolAflash
Parent article: KDE Plasma 6.5 released

> They said, they designed a display server protocol, which has less specific stuff in it's interface than X11.

Whoever might have said that, it sounds backwards.

Roughly speaking, X's philosophy is achieving higher-level behaviour by combining generic protocol primitives, whereas Wayland's philosophy is having dedicated protocol primitives for each specific higher-level behaviour.

The 2nd & 3rd paragraphs of the blog you linked to describe this distinction quite well.

> But then it turns out, that you can't even force a window on top of the others without a specific experimentatial Wayland addition.

FWIW, the Wayland PiP protocol isn't just about "always on top". The second-to-last paragraph of the blog you linked to goes into this.

For another example, a Wayland compositor could leave PiP windows visible in the same position even during exceptional situations like Exposé-style overviews, where windows are generally visible at different positions and sizes than normally. TTBOMK this isn't possible with X today, since the compositing manager can't distinguish between PiP windows and other "always on top" windows.

> I'm still waiting for a standartized Wayland protocol addition to set basic things like keyboard layout or screen resolution.

There's no universal consensus that those things are in scope for the Wayland protocol, so it's unlikely that they'll ever be part of Wayland protocols supported by all major compositors.

> And I have a very specific guess how many Wayland implementations will adapt to this new experiemental PiP Wayland API addition....

All the ones which care about the PiP use case, at least.

PiP protocol addition...!?

Posted Oct 23, 2025 19:03 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (13 responses)

> For another example, a Wayland compositor could leave PiP windows visible in the same position even during exceptional situations like Exposé-style overviews, where windows are generally visible at different positions and sizes than normally. TTBOMK this isn't possible with X today, since the compositing manager can't distinguish between PiP windows and other "always on top" windows.

One could probably do some window property settings, but then you're in the same boat as Wayland: does your window manager understand the property? Sure, a property is far simpler than a protocol, but it still need support "everywhere" to really be effective. Of interest to me: can I have, say, `mpv` use this to display on the *lock* screen while also denying/ignoring input to it? Kind of like a theater kiosk.

PiP protocol addition...!?

Posted Oct 24, 2025 7:21 UTC (Fri) by daenzer (subscriber, #7050) [Link]

> Of interest to me: can I have, say, `mpv` use this to display on the *lock* screen while also denying/ignoring input to it? Kind of like a theater kiosk.

Seems feasible in principle. The exact behaviour of PiP windows will be largely between the compositor and user.

PiP protocol addition...!?

Posted Oct 25, 2025 15:52 UTC (Sat) by raven667 (subscriber, #5198) [Link] (11 responses)

Lock screens are a funny business, I may be wrong but I think at least on GNOME the lock screen and the greeter runs on a separate VTY from any user session as their own user to keep the cred handling away from any user access at all. I would guess that's necessary to safely support fast user switching, which actually works reliably on GNOME, because on the lock screen you can legitimately log in as _someone_else_ and go to a different desktop than the one you locked in the first place. Because of that I don't think you can afford to have a regular user process interacting with the lock screen at all, that would work against the security model, but you should be able to make a simple compositor that runs a single fullscreen app and doesn't do anything else, like wayback for Xwayland, or even just some config settings in the desktop environment which supports this use case. You find similar settings on mobile devices where you can lock an app to the screen and don't allow switching away without a credential check as a parental control (hand the kid the phone to play a game but not get into your browsing history). So maybe PiP could be useful in some kiosk situation, maybe on a Smart TV, but I don't think that would be useful on the lock screen.

I'm not a desktop OS dev so I may be wrong in the details here, I'm sure more knowledgeable people will correct any glaring misconceptions.

PiP protocol addition...!?

Posted Oct 25, 2025 18:28 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> Lock screens are a funny business, I may be wrong but I think at least on GNOME the lock screen and the greeter runs on a separate VTY from any user session as their own user to keep the cred handling away from any user access at all.

Greeter yes (but that's how it works ≈everywhere), lock screen no. Lock screen is just built into the GNOME Shell, so the answer to GP's question boils down to how the Shell is implemented.

PiP protocol addition...!?

Posted Oct 27, 2025 9:40 UTC (Mon) by taladar (subscriber, #68407) [Link] (9 responses)

Logging in as as different user from a locked screen seems like an extreme niche feature in today's world where most people run their own personal devices.

PiP protocol addition...!?

Posted Oct 27, 2025 16:45 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

AFAIK, any "switch user" button kicks one out to the system-wide login manager rather than doing it directly. Not that I imagine one is *impossible*, but it seems like a lot of work for a quite niche feature with a simple workaround.

PiP protocol addition...!?

Posted Oct 28, 2025 8:22 UTC (Tue) by niner (subscriber, #26151) [Link] (7 responses)

If it was an "extreme niche", not every operating system would support it (ok, I don't know about Apple's). On our Android tablet me and my wife have different users because I prefer my system in English while she's more happy with German (among other reasons). On her laptop she herself has different users (with encrypted home directories) for private vs. work use because as a psychotherapist security is paramount. I have a bunch of users on my desktop because I have given access to my beefy machine to free software co-contributors who otherwise wouldn't have access to the compute power. Friends of mine have multiple users on the Windows PC attached to their TV because the kids must not have access to their full Steam library (and other things). Especially with kids I can see use for multiple accounts even on something as personal as a phone.

PiP protocol addition...!?

Posted Oct 28, 2025 9:03 UTC (Tue) by taladar (subscriber, #68407) [Link] (6 responses)

Having multiple users is one thing, allowing one to login graphically while another is still logged in with potentially system-filling numbers of applications running is what I meant about a niche feature.

PiP protocol addition...!?

Posted Oct 28, 2025 10:21 UTC (Tue) by Wol (subscriber, #4433) [Link]

> while another is still logged in with ...

Which certainly used to be the norm in my household. I'd be working away and someone else wanted the computer, so I'd just invoke the lock screen, let my stuff continue in the background, and they'd take over the computer.

But the kids have now flown the nest ...

Cheers,
Wol

PiP protocol addition...!?

Posted Oct 28, 2025 10:50 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

> Allowing one to login graphically while another is still logged in with potentially system-filling numbers of applications running is what I meant about a niche feature.

It's so niche that it's been a first-class feature of Microsoft Windows (NT family) for three decades, going at least as far back as NT 4.0. (Maybe all the way back to the beginning! Corporate deployments make heavy use of this feature. (That goes for desktop Linux deployments too!)

It's so "niche" that there's probably an order of magnitude more intentional deployments of that feature than there are total Linux desktop users.

PiP protocol addition...!?

Posted Oct 28, 2025 11:08 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

But is the lock screen in Windows "just" a process running as the session user (cf. `xlock`) or is it kernel-mediated in a way that you could have some semblance of trust that you're not being keylogged when you enter your password? It is implementing it directly in the screen locker (rather than punting to the login manager) that feels niche to me.

PiP protocol addition...!?

Posted Oct 28, 2025 12:37 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

It always used to be invoked by ctrl-alt-delete.

Which is a major security feature because it explicitly triggers a hardware NMI. So there's no point implementing a "fool you" lookalike screen - for anyone who knows how it's supposed to work, you need to actively patch into the interrupt handler to hijack it.

I don't think you CAN implement it in the user's lock screen (that or the lock screen is running as root), because you need to validate the new user's password, which only root or administrator can do.

Cheers,
Wol

PiP protocol addition...!?

Posted Oct 28, 2025 14:10 UTC (Tue) by pizza (subscriber, #46) [Link]

> I don't think you CAN implement it in the user's lock screen (that or the lock screen is running as root), because you need to validate the new user's password, which only root or administrator can do.

Validating the _current_ user's password also requires root privileges.

PiP protocol addition...!?

Posted Oct 28, 2025 15:40 UTC (Tue) by geert (subscriber, #98403) [Link]

Do you really want to log out (and have to reopen all applications, and reposition all windows?) every time you stand up from your computer, and let a family member use the computer?