ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
Company has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest10261
Guest10261 has quit [Remote host closed the connection]
Guest10262 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest10273
nerdopolis has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
zvarde1988303206779191685 has joined #wayland
zvarde1988303206779191685 has quit []
zvarde1988303206779191685 has joined #wayland
saumon has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
sima has joined #wayland
sevz has quit [Quit: Client quit]
kts has joined #wayland
kts has quit [Read error: Connection reset by peer]
rasterman has joined #wayland
d42 has joined #wayland
alatiera has quit [Quit: Connection closed for inactivity]
kts has joined #wayland
rv1sr has joined #wayland
kts has quit [Quit: Konversation terminated!]
<MrCooper>
zamundaaa[m]: mutter was fixed to handle fullscreen per spec, kwin could just follow suit :)
kts has joined #wayland
garnacho has joined #wayland
rtjure_ has joined #wayland
saumon has joined #wayland
mvlad has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<pq>
ManMower, this game event loop discussion stems from Wayland IPC essentially necessitating an event loop design, which seems to be not what games want to have, which creates problems for game toolkits that want to run well on Wayland.
leon-anavi has joined #wayland
<pq>
pax85, FWIW, my problem is with anything relying on a function call blocking, when that function call is not an epoll_wait() equivalent of the main event loop. Any arbitrary API call that blocks for its own special purposes is hard to reason about, and nearly impossible to unblock as needed when something happens elsewhere. It takes lots of careful design to make those blocking calls block just the right
<pq>
amount of time, and then even that fails when different apps use the same call for different throttling purposes.
i509vcb has quit [Quit: Connection closed for inactivity]
azerov has quit []
azerov has joined #wayland
<pq>
pac85, if one designs a game to rely on simulation and rendering run in sync, then it is so. I just wish someone would take the event loop design seriously, write a game engine for it from scratch, and see how well it can adapt all existing game designs while being an optimal design on Wayland. Unfortunately that cannot be transplanted to existing games, because the engine API would necessarily be different.
<pq>
It's also an immense amount of work, so I can only keep on wishing.
<pq>
One would start by choosing a good cross-platform event loop library.
<pq>
not by starting *that* from scratch
rtjure_ has quit []
kts has joined #wayland
<zamundaaa[m]>
MrCooper: sure, but if we fix that now, apps still won't be able to rely on it for years because the combination of LTS distros, Debian (which usually doesn't even ship our bugfix releases) and Flatpak exists...
<zamundaaa[m]>
I'd rather have the spec say what clients can actually rely on than give false promises
<emersion>
i don't think that's a good stance
<emersion>
if i have a compositor bug, i wouldn't ask the spec to be fixed, instead of fixing my compositor
<daniels>
kwin is clearly violating the spec, the spec encodes useful behaviour, just fix kwin instead of degrading the spec to the lowest common denominator of every compositor bug
<emersion>
if distros are bad at shipping bugfixes, then that's a distro issue, not a wayland issue, i think
<pq>
The cases I've heard where people want to see through a fullscreen window is when they want to see through the *whole compositor*, because they have hacked DRM KMS to allow the use of underlays from other processes while the compositor is running the primary plane.
<emersion>
the usual use-case is a fullscreen semi-transparent terminal
<zamundaaa[m]>
I can agree with those arguments in theory, but in practice it just makes the Wayland spec less reliable. Mutter only got fixed around a year ago as well...
<daniels>
pq: yeah, and if you're hacking up your system like that, you get to figure out how to put all those pieces together
<emersion>
this has been discussed before multiple times, and fullscreen transparent has security implications
<zamundaaa[m]>
To be clear here, I'm not talking abput changing the spec to make any use cases viable
<zamundaaa[m]>
But to change the spec from "compositors will do that" to "behavior with non-matching size and transparency is undefined" or something like that
<emersion>
zamundaaa[m]: do you mean that every compositor bug makes the spec less reliable?
<emersion>
there have been many many examples of compositor bugs before
<zamundaaa[m]>
emersion: to a degree, sure. But widespread compositor bugs specifically, definitely
<zamundaaa[m]>
And we did change the spec to match reality a few times before too
<pq>
zamundaaa[m], what's the reason to not have the opaque back-fill equivalent in kwin?
<daniels>
zamundaaa[m]: and then we end up either not offering clients what they want, or having a proliferation of extension versions where we say 'ah, if it exposes v7 then it'll do what we promised in v6', but if those take forever to propagate back to distros, then they won't get what we want, so the spec just shrinks
<emersion>
we did that before because we believed the spec was wrong
<emersion>
here it's not
<daniels>
yeah
<zamundaaa[m]>
daniels: clients can implement this one themselves with subsurfaces just fine. There's no need to have this in xdg shell
<daniels>
what about the clients who expected that the spec would do what it said? they'd have to retrospectively go back and work around the bug, which again has the same issue wrt propagating back into stable distros
<zamundaaa[m]>
pq: the reason we don't have it implemented already is mostly that it adds a bunch of annoying if(fullscreen) checks - and that there never way any need for it, as clients don't use it. I'm talking about the client perspective and not the compositor side though, fixing it for the next version of KWin wouldn't be that difficult I think
<zamundaaa[m]>
daniels: such clients don't exist. Or at least I have never seen a single one
<daniels>
I have :)
<MrCooper>
yeah, mutter wasn't fixed just for fun
<daniels>
if none of the clients that get used with kwin care about it though, then the fact kwin doesn't implement it correctly makes this whole discussion kind of moot? like, you can just fix it in kwin and life will continue
<MrCooper>
pretty sure I've hit issues with weston-simple-egl
<zamundaaa[m]>
daniels: which app?
<zzag>
"and fullscreen transparent has security implications" that's quite a stretch
<daniels>
zamundaaa[m]: at least one media player - I forget which
<pq>
zamundaaa[m], I'm quite confused about the benefits of your proposal. Retroactively changing spec needs really good justification. OTOH, it's normal for compositors to have bugs that go unnoticed a long time and then get fixed when someone notices.
<ifreund>
weaking the spec by leaving more compositor behavior undefined will always make it more difficult to write portable clients
<zzag>
pq: we have not implemented the fullscreen mode according to the spec because it's just too hard to get right and because it's going to break the case of translucent terminals which will be a regression in comparison to x11 session
<ifreund>
I don't think weaking the spec is a generally positive thing when incosistency between compositors is discovered
<ifreund>
it should only be done if it is the least bad option IMO
<zzag>
imho such fullscreen mode should be covered by a separate protocol
<ifreund>
s/weaking/weakening/
<zamundaaa[m]>
ifreund: saying it's undefined doesn't weaken the spec, it just tells clients to implement the behavior they want with subsurfaces, which works everywhere
<ifreund>
taking something that is currently well-defined and making that thing undefined is pretty much the definition of weakening a spec no?
<pq>
zamundaaa[m], it does invalidate existing toolkits. It's basically telling toolkits to re-implement fullscreen.
<pq>
zzag, I could say the same about transparent fullscreen.
<zamundaaa[m]>
ifreund: It's only well defined in theory, not in practice
<ifreund>
yep, instead of fixing the compositor that does not obey the spec you're saying that all clients which trust that compositors uphold the current spec should be fixed instead
<pq>
The fact is that the current spec clearly specifies a behaviour. If you need a different behaviour, the normal action is to extend the protocol to define the other behaviour.
<zzag>
pq: you assume that toolkits expect that a fullscreen window has an opaque background, but it's not really the case. and changing it can actually break some apps
<pq>
propose a better fullscreen state to be added, don't redefine what already clearly written.
<zzag>
for example, like image viewer in telegram
<daniels>
zzag: that seems totally backwards - writing something which deliberately contradicts the spec, and saying that the specified behaviour should be implemented in another extension?
<pq>
zzag, all the more reason to *add* a new window state to cater for it.
kts has quit [Quit: Konversation terminated!]
<daniels>
like, as it is, clients can’t rely on transparent behaviour because only kwin does that
<zzag>
pq: I disagree that we need a new state for that
<zzag>
daniels: if we could go back in time, we would ask to change set_fullscreen behavior because it doesn't work for us. I'm not sure how much Martin has been involved at that time or whether he had in mind the issue that we have
<zzag>
issues*
<zamundaaa[m]>
pq: last time I proposed adding a new state for the translucent fullscreen feature I got a lot of pushback about that too...
<zamundaaa[m]>
But that wouldn't guarantee the compositor honors that the surface stays translucent either
nnm has quit [Remote host closed the connection]
nnm has joined #wayland
<MrCooper>
adding to the point above, changing the spec to say it's undefined means clients can't rely on translucency, so it wouldn't even solve your issue
<daniels>
yeah, doing unscaled translucent when everyone else does scaled solid is ... not helpful for clients. doing unscaled translucent when the spec calls it undefined isn't helpful for clients either.
<daniels>
if you don't care about clients being portable, then just make your own kwin_unscaled_translucent_popover ext and have them use that
<daniels>
if you do care about clients being portable, then spec the behaviour you want to guarantee
<zamundaaa[m]>
I think there's some confusion here. There's no need to guarantee clients that they're getting translucency in fullscreen - that's a feature users care about, not applications
<zamundaaa[m]>
Saying the behavior is undefined in the spec would merely mean that clients that need to rely on an opaque background would have to implement that themselves, not the other way around
* daniels
shrugs
<emersion>
if you submit a semi-transparent buffer and the compositor draws that over black color, that won't looik very good?
<zamundaaa[m]>
emersion: if the client submits a translucent buffer, it can't rely on anything specific being behind the window either way
<emersion>
it can rely on a solid black
<pq>
solid black wasn't exactly specified, was it?
columbarius has joined #wayland
<zamundaaa[m]>
pq: yeah it's unspecified
<pq>
just that you don't see through to anything else
<zamundaaa[m]>
I think the intention was that the alpha channel could just be ignored, so that the compositor can do direct scanout of the buffer
co1umbarius has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
But I don't think it's implemented that way in compositors?
<emersion>
direct scanout doesn't mean alpha channel is ignored
<pq>
No, but the math would work like that *if* the backdrop is black.
<emersion>
there is an implicit black fill in KMS
<emersion>
"If the fullscreened surface is not opaque, the compositor must make sure that other screen content not part of the same surface tree are not visible below the fullscreened surface."
<emersion>
that's your issue right? the issue is not the black fill?
<pq>
zamundaaa[m], Wayland defaults to pre-multiplied alpha.
<zamundaaa[m]>
pq: right
<pq>
blending to black background is mathematically equal to ignoring alpha
<daniels>
we're sort of going round in circles; the core point though is that deliberately implementing behaviour which contradicts the spec, then suggesting the spec should be changed 6 years later to support totally different usecases, seems ... not great
<emersion>
yeah, i would suggest working on a protocol ext if you care about this use-case
fmuellner has joined #wayland
<pq>
So the rationale to turn this previously clear and explicit behaviour to unspecified is that then end users can configure their compositors to do what they want per-window? Is that decision really that arbitrary that it's not tied to the application at all?
<zamundaaa[m]>
I must repeat here again that I am not saying the spec should be changed to support other use cases... and that I already proposed adding a mode to the spec to support the use cases independently of that. Which noone was happy with either
<daniels>
I don't mind there being an additional, separate, mode/request to support the transparent-popover case
<emersion>
i don't think this new mode should be available to all clients, because security
<daniels>
yeah, I'm not sure I'd really want to support system-modal popovers
<pq>
emersion, I have a hard time seeing the security aspect today.
<daniels>
but at least it'd be very clear to clients what they were requesting and what they could expect
<zzag>
emersion: how's it different from maximizing a translucent toplevel?
<emersion>
pq, imitate system UI
<emersion>
zzag: maximize doesn't cover the whole screen
<zzag>
emersion: a maximized window can pretend to be a password dialog
<pq>
It's still just a fullscreen top-level that you can switch away from. It's difficult to imitate system UI, because you cannot screenshot or anything else to know where the real e.g. pinentry window is. And if position is unimportant, you can already mimick system UI with just a regular window.
<zzag>
it doesn't have to cover the whole work area
<emersion>
zzag: i don't undersdtand
<zzag>
emersion: a maximized window can render a password dialog inside, thus posing a security risk
<zzag>
my point is that absolutely anything can be abused
<zzag>
and present a security issue
<emersion>
it won't be able to look the same as system UI
<pq>
If identifying system UI is important, then system UI should be identifiable with something that cannot be mimicked. That would probably lean towards a System Access Key etc. that would somehow mark (remove, fade, ...) all non-system windows.
<emersion>
also see: android fullscreen restrictions
<pq>
any non-system window that remains presented as-is during SAK has a chance to pose as system UI
<emersion>
SAK?
<pq>
System Access Key... or was it Secure Access Key
<pq>
usually it's Ctrl+Alt+Del intercepted by the system, but it could as well be a portal for system provided pinentry if you need to input passwords.
<emersion>
i don't know what that is
<emersion>
the thing from Windows 95 or something?
<pq>
a compositor could have it's SAK, or the same could be triggered via a portal
<pq>
if a portal is used to ask for a password, it does not need to me modal; the compositor could switch between normal and "annotated" display modes mased on whether this system dialog is active or not.
<pq>
*based
<pq>
while the kernel SAK just kills everything that might interpose, a compositor SAK can just mark all untrusted windows.
<pq>
like gray them out while system UI is colorful, or something
glennk has joined #wayland
<MrCooper>
pq: gnome-shell dialogs have a translucent shadow covering the whole desktop; this could be faked in theory with translucent fullscreen, not with a maximized window though
<pq>
aha
<emersion>
i assumed you used gnome-shell and was aware of this :o
<emersion>
were*
<pq>
I use GNOME extremely little.
<emersion>
sorry then!
<emersion>
scoop: none of the main wayland developers actually use wayland, they are all stuck on openbox with xorg
<zzag>
"not with a maximized window though" given the default UI, the maximized window won't cover only small part of the screen corresponding to the top bar, it can be easily overlooked
<emersion>
i suppose that would be more jarring on KDE, where the bar is bigger and not solid black ;)
<MrCooper>
the title bar of maximized windows is below the gnome-shell top bar, I'd say it'd be pretty obvious
<zzag>
MrCooper: well, you've got csd thing going on :)
<zzag>
one could just not draw it?
<emersion>
yeah
<MrCooper>
hmm, touché
<pq>
emersion, I didn't say so, I use Plasma at home. But, yes, fluxbox, because "my workflow". :-p
<MrCooper>
in my case, gkrellm would save me, since it prevents maximized windows from covering the whole screen, but for most users it could work
<emersion>
pq: aha, didn't think it would actually turn out to be true! :P but yeah, use whatever is best for you
<pq>
yeah, that's why I thought of SAK-mode straight in the compositor with a clear indication of non-system windows.
<emersion>
the greyed-out windows behind security dialogs sounds like a more obvious choice, but also, designers might be unhappy
<emersion>
probably there could be a bunch of other effects you could pick from
<pq>
emersion, I set this thing up in 2003, why fix it as long as it's working...
<emersion>
like blur
<pq>
yes
<emersion>
although the KDE ext allows arbitrary apps to replicate that one
<pq>
eh heh
<pq>
a) the end user must know to verify the SAK-mode (either by unfakeable looks, or via an actual SAK press), and b) have all sensitive dialogs be system dialogs via portals that trigger the SAK-mode when activated.
<pq>
hmm, system dialogs could contain a note: "You can verify this is a system dialog by pressing..."
<emersion>
orthogonal but requiring xdg-activation would be a great step forward
<swick[m]>
yeah, we also don't require that right now and it's bad
<emersion>
pq, i assume no-one born after 2000 would want to press SAK
<swick[m]>
had steam pop up in the front recently when I entered a password
<pq>
emersion, how else do you figure out if what you see if fake or not, if not pressing a global compositor hotkey that will reveal all fakes?
<emersion>
pq, by revealing all fakes always, for instance
<pq>
how do you do that?
<emersion>
your gray-out idea would be a way
<emersion>
a way that also wouldn't work nice for me, i have just black-and-white on most my windows
<pq>
how do you know it's not just a fullscreen window drawing gray stuff?
<emersion>
i think a special status item in the taskbar could help too
<pq>
but fullscreen window covers taskbars
<pq>
opaque fullscreen window, even
<emersion>
hence semi-transparent for system UI…
<pq>
But if you could spare a portion of your screen estate where no regular app ever gets to show anything, that would do - but then also fullscreen cannot extedn there.
<pq>
opaque fullscreen window can just draw a picture of some desktop as if it was behind something semi-transparent
<emersion>
macbooks have this screen bar need the keyboard
<emersion>
a dedicated LED would probably do as well
<emersion>
but yeah, at some point you need hw support
<emersion>
switch RGB keyboard backlight to red? or pulse?
<emersion>
there are porbably many ways
<pq>
whoever happens to have that hardware
<pq>
a compositor hotkey seems like the most universal solution
<pq>
app contacts a portal for pinentry, portal triggers a system pinentry dialog (a normal window, not modal), and every time the dialog is activated the compositor reveals the window origins. If the user presses the SAK key while the dialog is active, nothing should happen.
<pq>
If the dialog is fake, the compositor is not in reveal mode, user presses SAK, and the dialog is revealed as non-system.
<daniels>
train a neural network on system dialogs, and if a client pops up something which looks too similar, shoot it
<emersion>
ahahah
<pq>
I'm absolutely serious with this.
Moprius has joined #wayland
<zamundaaa[m]>
Judging by the discussion here, I hope we can all agree that security is not a solved problem by just restricting apps from being translucent, and needs actual active effort from the compositor?
<zamundaaa[m]>
So if I make a MR adding a set_translucent_fullscreen request to xdg shell, it won't get shut down with "but security" this time?
<pq>
well, I hear it would conflict with GNOME's current UI...
<zamundaaa[m]>
Mutter doesn't have to support it
<pq>
point
<pq>
I agree about security, at least.
<pq>
and I have no reason to reject a non-exclusive fullscreen mode
<emersion>
as long as it's optional
<pq>
all window states are optional to a compositor
<ifreund>
it's nice that we have a wm_capabilites event to handle that sort of optionality now