08:22 MrCooper: zamundaaa[m]: mutter was fixed to handle fullscreen per spec, kwin could just follow suit :)
08:47 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.
08:52 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
08:52 pq: amount of time, and then even that fails when different apps use the same call for different throttling purposes.
09:13 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.
09:13 pq: It's also an immense amount of work, so I can only keep on wishing.
09:14 pq: One would start by choosing a good cross-platform event loop library.
09:15 pq: not by starting *that* from scratch
09:47 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...
09:48 zamundaaa[m]: I'd rather have the spec say what clients can actually rely on than give false promises
09:50 emersion: i don't think that's a good stance
09:50 emersion: if i have a compositor bug, i wouldn't ask the spec to be fixed, instead of fixing my compositor
09:53 wlb: weston Issue #428 closed \o/ (weston-8.0.0: eventX input devices are ignored after updating systemd from 244 to 245 https://gitlab.freedesktop.org/wayland/weston/-/issues/428)
09:53 daniels: I agree with emersion
09:54 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
09:54 emersion: if distros are bad at shipping bugfixes, then that's a distro issue, not a wayland issue, i think
09:57 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.
09:59 emersion: the usual use-case is a fullscreen semi-transparent terminal
10:00 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...
10:00 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
10:01 emersion: this has been discussed before multiple times, and fullscreen transparent has security implications
10:01 zamundaaa[m]: To be clear here, I'm not talking abput changing the spec to make any use cases viable
10:02 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
10:02 emersion: zamundaaa[m]: do you mean that every compositor bug makes the spec less reliable?
10:03 emersion: there have been many many examples of compositor bugs before
10:03 zamundaaa[m]: emersion: to a degree, sure. But widespread compositor bugs specifically, definitely
10:04 zamundaaa[m]: And we did change the spec to match reality a few times before too
10:04 pq: zamundaaa[m], what's the reason to not have the opaque back-fill equivalent in kwin?
10:05 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
10:06 emersion: we did that before because we believed the spec was wrong
10:06 emersion: here it's not
10:06 daniels: yeah
10:06 zamundaaa[m]: daniels: clients can implement this one themselves with subsurfaces just fine. There's no need to have this in xdg shell
10:07 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
10:07 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
10:08 zamundaaa[m]: daniels: such clients don't exist. Or at least I have never seen a single one
10:09 daniels: I have :)
10:10 MrCooper: yeah, mutter wasn't fixed just for fun
10:10 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
10:10 MrCooper: pretty sure I've hit issues with weston-simple-egl
10:10 zamundaaa[m]: daniels: which app?
10:10 zzag: "and fullscreen transparent has security implications" that's quite a stretch
10:11 daniels: zamundaaa[m]: at least one media player - I forget which
10:12 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.
10:13 ifreund: weaking the spec by leaving more compositor behavior undefined will always make it more difficult to write portable clients
10:14 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
10:14 ifreund: I don't think weaking the spec is a generally positive thing when incosistency between compositors is discovered
10:14 ifreund: it should only be done if it is the least bad option IMO
10:14 zzag: imho such fullscreen mode should be covered by a separate protocol
10:15 ifreund: s/weaking/weakening/
10:15 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
10:16 ifreund: taking something that is currently well-defined and making that thing undefined is pretty much the definition of weakening a spec no?
10:16 pq: zamundaaa[m], it does invalidate existing toolkits. It's basically telling toolkits to re-implement fullscreen.
10:17 pq: zzag, I could say the same about transparent fullscreen.
10:17 zamundaaa[m]: ifreund: It's only well defined in theory, not in practice
10:17 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
10:18 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.
10:19 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
10:19 pq: propose a better fullscreen state to be added, don't redefine what already clearly written.
10:19 zzag: for example, like image viewer in telegram
10:19 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?
10:20 pq: zzag, all the more reason to *add* a new window state to cater for it.
10:20 daniels: like, as it is, clients can’t rely on transparent behaviour because only kwin does that
10:20 zzag: pq: I disagree that we need a new state for that
10:23 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
10:23 zzag: issues*
10:24 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...
10:26 zamundaaa[m]: But that wouldn't guarantee the compositor honors that the surface stays translucent either
10:59 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
11:05 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.
11:06 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
11:06 daniels: if you do care about clients being portable, then spec the behaviour you want to guarantee
11:07 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
11:08 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
11:10 daniels:shrugs
11:10 emersion: if you submit a semi-transparent buffer and the compositor draws that over black color, that won't looik very good?
11:12 zamundaaa[m]: emersion: if the client submits a translucent buffer, it can't rely on anything specific being behind the window either way
11:12 emersion: it can rely on a solid black
11:12 pq: solid black wasn't exactly specified, was it?
11:13 zamundaaa[m]: pq: yeah it's unspecified
11:13 pq: just that you don't see through to anything else
11:14 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
11:14 zamundaaa[m]: But I don't think it's implemented that way in compositors?
11:14 emersion: direct scanout doesn't mean alpha channel is ignored
11:14 pq: No, but the math would work like that *if* the backdrop is black.
11:14 emersion: there is an implicit black fill in KMS
11:15 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."
11:15 emersion: that's your issue right? the issue is not the black fill?
11:15 zamundaaa[m]: pq: not with alpha between 0 and 1
11:16 pq: zamundaaa[m], yes, it does.
11:16 emersion: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml?ref_type=heads#L1048
11:16 pq: zamundaaa[m], Wayland defaults to pre-multiplied alpha.
11:16 zamundaaa[m]: pq: right
11:17 pq: blending to black background is mathematically equal to ignoring alpha
11:17 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
11:17 emersion: yeah, i would suggest working on a protocol ext if you care about this use-case
11:19 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?
11:19 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
11:19 daniels: I don't mind there being an additional, separate, mode/request to support the transparent-popover case
11:20 emersion: i don't think this new mode should be available to all clients, because security
11:20 daniels: yeah, I'm not sure I'd really want to support system-modal popovers
11:20 pq: emersion, I have a hard time seeing the security aspect today.
11:20 daniels: but at least it'd be very clear to clients what they were requesting and what they could expect
11:21 zzag: emersion: how's it different from maximizing a translucent toplevel?
11:21 emersion: pq, imitate system UI
11:21 emersion: zzag: maximize doesn't cover the whole screen
11:22 zzag: emersion: a maximized window can pretend to be a password dialog
11:22 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.
11:22 zzag: it doesn't have to cover the whole work area
11:23 emersion: zzag: i don't undersdtand
11:23 zzag: emersion: a maximized window can render a password dialog inside, thus posing a security risk
11:24 zzag: my point is that absolutely anything can be abused
11:24 zzag: and present a security issue
11:24 emersion: it won't be able to look the same as system UI
11:24 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.
11:25 emersion: also see: android fullscreen restrictions
11:26 pq: any non-system window that remains presented as-is during SAK has a chance to pose as system UI
11:27 emersion: SAK?
11:27 pq: System Access Key... or was it Secure Access Key
11:28 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.
11:28 emersion: i don't know what that is
11:29 emersion: the thing from Windows 95 or something?
11:29 emersion: that sounds like a thing from the past
11:30 pq: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/security/sak.rst
11:30 pq: ah, Secure Attention Key
11:31 pq: a compositor could have it's SAK, or the same could be triggered via a portal
11:32 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.
11:32 pq: *based
11:34 pq: while the kernel SAK just kills everything that might interpose, a compositor SAK can just mark all untrusted windows.
11:34 pq: like gray them out while system UI is colorful, or something
11:38 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
11:38 pq: aha
11:39 emersion: i assumed you used gnome-shell and was aware of this :o
11:39 emersion: were*
11:39 pq: I use GNOME extremely little.
11:42 emersion: sorry then!
11:43 emersion: scoop: none of the main wayland developers actually use wayland, they are all stuck on openbox with xorg
11:43 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
11:45 emersion: i suppose that would be more jarring on KDE, where the bar is bigger and not solid black ;)
11:45 MrCooper: the title bar of maximized windows is below the gnome-shell top bar, I'd say it'd be pretty obvious
11:45 zzag: MrCooper: well, you've got csd thing going on :)
11:46 zzag: one could just not draw it?
11:46 emersion: yeah
11:46 MrCooper: hmm, touché
11:47 pq: emersion, I didn't say so, I use Plasma at home. But, yes, fluxbox, because "my workflow". :-p
11:47 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
11:49 emersion: pq: aha, didn't think it would actually turn out to be true! :P but yeah, use whatever is best for you
11:49 pq: yeah, that's why I thought of SAK-mode straight in the compositor with a clear indication of non-system windows.
11:49 emersion: the greyed-out windows behind security dialogs sounds like a more obvious choice, but also, designers might be unhappy
11:50 emersion: probably there could be a bunch of other effects you could pick from
11:50 pq: emersion, I set this thing up in 2003, why fix it as long as it's working...
11:50 emersion: like blur
11:51 pq: yes
11:51 emersion: although the KDE ext allows arbitrary apps to replicate that one
11:51 pq: eh heh
11:55 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.
11:58 pq: hmm, system dialogs could contain a note: "You can verify this is a system dialog by pressing..."
11:58 emersion: orthogonal but requiring xdg-activation would be a great step forward
11:58 swick[m]: yeah, we also don't require that right now and it's bad
11:59 emersion: pq, i assume no-one born after 2000 would want to press SAK
11:59 swick[m]: had steam pop up in the front recently when I entered a password
11:59 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?
12:00 emersion: pq, by revealing all fakes always, for instance
12:00 pq: how do you do that?
12:01 emersion: your gray-out idea would be a way
12:01 emersion: a way that also wouldn't work nice for me, i have just black-and-white on most my windows
12:01 pq: how do you know it's not just a fullscreen window drawing gray stuff?
12:01 emersion: i think a special status item in the taskbar could help too
12:02 pq: but fullscreen window covers taskbars
12:02 pq: opaque fullscreen window, even
12:03 emersion: hence semi-transparent for system UI…
12:03 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.
12:04 pq: opaque fullscreen window can just draw a picture of some desktop as if it was behind something semi-transparent
12:04 emersion: macbooks have this screen bar need the keyboard
12:04 pq: that'd work
12:04 emersion: i think MNT reform has this too
12:08 emersion: (https://mntre.com/reform2/handbook/input.html#oled-menu)
12:08 emersion: a dedicated LED would probably do as well
12:08 emersion: but yeah, at some point you need hw support
12:09 emersion: switch RGB keyboard backlight to red? or pulse?
12:09 emersion: there are porbably many ways
12:09 pq: whoever happens to have that hardware
12:10 pq: a compositor hotkey seems like the most universal solution
12:13 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.
12:13 pq: If the dialog is fake, the compositor is not in reveal mode, user presses SAK, and the dialog is revealed as non-system.
12:14 daniels: train a neural network on system dialogs, and if a client pops up something which looks too similar, shoot it
12:15 emersion: ahahah
12:15 pq: I'm absolutely serious with this.
12:16 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?
12:17 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?
12:17 pq: well, I hear it would conflict with GNOME's current UI...
12:17 zamundaaa[m]: Mutter doesn't have to support it
12:18 pq: point
12:18 pq: I agree about security, at least.
12:19 pq: and I have no reason to reject a non-exclusive fullscreen mode
12:20 emersion: as long as it's optional
12:21 pq: all window states are optional to a compositor
12:21 ifreund: it's nice that we have a wm_capabilites event to handle that sort of optionality now
12:34 wlb: weston Issue #839 closed \o/ (Panfrost (rk3399) NV12 sampling broken https://gitlab.freedesktop.org/wayland/weston/-/issues/839)
12:41 wlb: weston Merge request !1418 opened by Pekka Paalanen (pq) backend-drm: make libdisplay-info mandatory https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1418 [DRM/KMS backend]
12:44 emersion: hm maybe we should make a new libdisplay-info release
12:47 pq: emersion, I don't see there anything that would actually warrant a 0.2.0 except the version number was already bumped. 0.1.2 then?
12:47 emersion: pq, one field was changed from int32 to int64 i think…
12:48 pq: oh
12:48 emersion: it's a bit unfortunate :/
12:48 pq: ah, so it was.
12:48 pq: nah, it's life. Numbers are cheap. :-)
12:49 emersion: alternatively if we want a bugfix release i can write a patch which just clamps to INT32_MAX or something
12:50 emersion: i think there's a whole bunch of swick[m] MRs i need to have another look at also?
12:50 pq: makes no difference to me, Weston wouldn't even need that fix.
12:52 pq: I'm just trying to get back to my "use libdisplay-info color API I added" Weston project, three days before holiday season. :-)
12:53 pq: Def not gonna make it to prove the libdisplay-info API.
12:54 pq: emersion, but if you do make a 0.2.0 release, I'd bump Weston to use it before making libdisplay-info mandatory.
12:57 soreau:yawns
13:33 emersion: pq, do you want to merge that new API MR before the next lbdi release?
13:33 emersion: libdi*
13:35 pq: not necessarily, it would push the release back to Jan or even Feb
13:38 pq: If you want to have a 0.2.0 release this year, please go ahead.
15:17 pq: emersion, I think I'll get back to the high-level colorimetry API in Jan.
15:47 wlb: weston Merge request !1419 opened by Michael Olbrich (mol) backend-drm: improve logging and commit error handling https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1419
17:20 wlb: weston Merge request !1420 opened by Khem Raj (kraj) libweston,tools: Include libgen.h for basename signature https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1420
17:29 bwidawsk: what's an example usage for creating a popup with null parent and setting it later?
18:11 vyivel: bwidawsk: https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:request:get_popup, for example
18:11 bwidawsk: vyivel: yeah, I suppose my question was more like, why do this?
18:12 bwidawsk: but that makes sense
18:12 bwidawsk: layer instead of toplevel
18:12 bwidawsk: thanks