00:00bwidawsk: I'll submit one for fractional scaling shortly too
00:07wlb: wayland-protocols Merge request !271 opened by Ben Widawsky (bwidawsk) fraction-scale: clarify scale expecations https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/271
03:11wlb: weston Issue #861 opened by M B (mwberry) [feature request] Weston does not scale launcher icons to match the launcher width https://gitlab.freedesktop.org/wayland/weston/-/issues/861
03:11wlb: weston Issue #857 closed \o/ (Weston launcher renders icons incorrectly depending on size and screen rotation https://gitlab.freedesktop.org/wayland/weston/-/issues/857)
08:06riteo: folks, sorry for bringing this once more, but I'm having a real hard time figuring the proper nature of this issue
08:07riteo: So, I've thought about the frame issue once more and I wonder if all we need isn't really just a "surface occluded" flag, with which to know that we can't rely on frame events anymore
08:09riteo: Another reason for this though is the fact that it looks like (please correct me if I'm wrong) to "default" to vsync rate when it comes to "pacing" the WSI, if you get what I mean, which would be a bit un-ideal with "interface-y" things, like for example the godot editor
08:10riteo: (I know the surface occluded flag has already been discussed but it got phased out in favor of the commit queue stuff I think, but I think that it might not fix the problem fully, although it will help a lot)
08:12riteo: I'm really sorry for asking this, but if I'm saying something dumb I beg somebody to explain me the issue a bit as I'm not a graphics person at all and I think I might either be missing something or taking something impossible for granted. I really do want to allow game engines like godot engine their best possible chance at working up to their potential
08:14kennylevinsen: There's the suspended flag
08:15riteo: it's for "client" things though, not full rendering shenanigans I got told
08:15riteo: like, "calm down animations a bit thx"
08:15riteo: and it's for xdg_toplevel only, which further brings up my point
08:16riteo: In short, my proposed approach is a bit more similar to "the old way" I suppose
08:17riteo: basically, if we don't stall anymore on presenting because of the FIFO queue (that's how it works I hope), we can then fetch at whatever rate this flag and "optimize" rendering out
08:17riteo: which is what godot is built to do and probably a lot of other game engines, as they're paced from the WSI and not the compositor.
08:18riteo: that would still mean that compositors can't easily "throttle" them down but I'm not sure how that could be fixed honestly, outside of some "interference" WSI side, if something like this is even possible
08:19riteo: I genuinely can't think of a better way out and this is confusing me down a bit tbh
08:20kennylevinsen: If you didn't rely on having WSI block you could do all this already
08:22riteo: The issue is that we have no reliable rate at which to fetch the frame event I suppose
08:23kennylevinsen: Render at whatever rate, wait on frame event with a high timeout to unstall, go into background mode when suspend is set (likely shortly after you got frame event timeout)
08:23riteo: we're basically reinventing suspension but worse
08:23riteo: but maybe I'm just too dumb to understand this, maybe this is the most correct approach after all
08:24kennylevinsen: You're not reinventing suspension if you *use* suspension
08:24riteo: what is suspension, really, from a client's PoV?
08:24riteo: an undefined time elapsed since the last frame event?
08:26kennylevinsen: It says that the compositor is not normally rendering the surface. It's a hand-wavy way to say "stop and release your resources, you're not visible and nobody cares about you". Hand-wavy because it's not guaranteed sent in all cases where the surface is not seen
08:26riteo: wait, are you referring to the xdg_toplevel event?
08:26kennylevinsen: Yes
08:27kennylevinsen: Hence "you can already do all this"
08:27kennylevinsen: Godot can use that event itself
08:28riteo: I'm pretty sure that we're still supposed to render if we get a suspended event
08:28riteo: lemme give a look
08:28riteo: like, it's not guaranteed that receiving it will mean that we can stop rendering
08:30riteo: mh, it says that it's not ordinarily being repainted, which I'm not sure it means we can use it this way
08:30kennylevinsen: reacting to frame events asynchronously would be better, but you definitely shouldn't be actively rendering in the suspended state. What can happen is that someone might want *a* new franr for a preview at some point
08:30kennylevinsen: frame
08:31kennylevinsen: Not sure if other compositors unset the suspended state in those cases when asking for a frame
08:35riteo: wait!
08:35riteo: I think you're right!
08:35riteo: the MR body itself says: "In this state, clients can choose to take meaningful action such as suspending any processing which would drive a repaint loop"
08:36riteo: So that's the intent of the protocol I suppose, which would explain the "not ordinarily repainted" thing
08:36riteo: And the QT folks apparently use it to avoid the exact "workaround" that we were describing before: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/201#note_1962481
08:37riteo: I think that this is indeed enough to fix _that_ part of the bigger problem space! I don't want to celebrate yet, but this feels like I might've misunderstood things along the way, perhaps due to the usual X-Y problem
08:38riteo: If the answer to "how do I stop godot from having to guess when it can stop drawing" is this I'll be really happy
08:39riteo: (before the "you just need to know when to draw", our reliance on the WSI makes it impossible AFAICT, so we have to go the other way. I still really like the frame semantics but they're not the right choice for this sadly)
08:39riteo: (to be clear, not by themselves)
08:40riteo: kennylevinsen: thanks as usual for your help and point of view
08:40kennylevinsen: You're welcome
08:43kennylevinsen: One point is that there isn't a guarantee that it will come *before* frame callbacks stall. So you still need e.g. timeout on waiting for frame callbacks or something - but once you get suspended state you can cleanly move to "background" mode without guesses.
08:44kennylevinsen: But try it out and see
08:46riteo: we'll still probably have to "emulate vsync" (basically MAILBOX and listen to frame events) anyways so that's not a problem I suppose
08:47riteo: and from what I've seen that looks "by design" when more advanced clients want to manually handle frame events
08:48riteo: plus the WSI is kinda broken it looks like, judging from the commit queue stuff, so it really shouldn't be a problem. I hope I won't find some catch and have an existential crisis again lmao
08:48riteo: it really wasn't a good idea to get into wayland with something such as complex and annoying as this oof
08:49riteo: (not really godot as much as the whole WIP protocol shenanigans)
08:49riteo: I don't think I'm terribly useful here outside of messing around with godot, hope y'all don't mind
08:52riteo: (don't take this as me giving up, I still really want to help to the extent possible and I'm open to all your PoVs and information)
16:03wlb: weston Issue #862 opened by Vikas Korjani (vkorjani) 8K@60 tiled display with 2 x DP connection https://gitlab.freedesktop.org/wayland/weston/-/issues/862
16:58wlb: wayland-protocols Issue #172 opened by Markus Bauermeister (bauermeistermarkusdev) ext-session-lock-v1 question https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/172
17:58q234rty: seems like there's a race where two people try to answer the same question :)
19:52kennylevinsen: q234rty: yes lol
23:43ids1024: Is it ever actually valid to have a dmabuf buffer with different modifiers per plane? Given GBM doesn't even seem to have per-plane modifiers (only `gbm_bo_get_modifier`).
23:50zamundaaa[m]: ids1024: all planes always have the same modifier
23:52ids1024: Was there some expectation that wouldn't be the case when `EGL_EXT_image_dma_buf_import_modifiers` and `linux-dmabuf-unstable-v1` were designed with a modifier specified for each plane?
23:52ids1024: It might be good to document in `linux-dmabuf-unstable-v1` that the modifiers should all be the same, if that's always the case.
23:57wlb: wayland Merge request !358 opened by Thomas Lukaszewicz (tluk) Draft: wayland-server: Add wl_client_add_event_dispatch_listener https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/358