00:48 wlb: wayland Merge request !327 opened by Peter Hutterer (whot) Add a triage-policies file for bugbot https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/327
07:36 jadahl: so how are other compositors enforcing `buffer_size % buffer_scale == 2` today? in mutter we started todo, and at first we got crash reports about gtk cursor with custom themes so we disabled it for cursors, but now also it's causing Qt clients to crash left and right too because of it
07:36 emersion: wlroots is enforcing it, except for cursors
07:37 jadahl: have you seen any users complaining about it taking down qt clients?
07:38 emersion: that doesn't ring a bell
07:39 emersion: hm, there is https://github.com/swaywm/sway/issues/6252
07:39 jadahl: seems to be the case anyhow. maybe its a race somewhere in qt
07:39 emersion: but it was at a time when we didn't kill the client
07:40 jadahl: emersion: the logs from 'haruna' shows some race condition: https://gitlab.gnome.org/GNOME/gtk/-/issues/5869#note_1780517
07:43 q234rty: hmmm https://bugreports.qt.io/browse/QTBUG-93380 claims that this is fixed
07:45 emersion: sway users in general don't run outdated software, so i'm biased when it comes to bug reports
08:00 psykose: that bug report fix is not in a release
08:01 davidre: Yes 6.6 is a Beta
08:07 jadahl: is there some way to run a Qt program with debug logging about EGLSurface sizes and things like that?
08:11 davidre: If there is d_ed is likely to know
08:13 d_ed[m]: David Redondo: Qt logging rules should suffice. I'm on my phone, can you share the relevant env var
08:13 davidre: The question is which one :D
08:14 davidre: QT_LOGGING_RULES="*=true" will probably to much to handle
08:14 jadahl: the information I want to get is what was passed to wl_egl_window_resize before the commit
08:16 davidre: I dont' see any direct debugging of it
08:16 davidre: Just grepping that function I think the relevant code is in https://invent.kde.org/qt/qt/qtwayland/-/blob/dev/src/hardwareintegration/client/wayland-egl/qwaylandeglwindow.cpp#L66
08:17 jadahl: yea, can't see any, thanks for checking
08:17 davidre: This is called when the fractional scale changes
08:18 davidre: And afterwards there is a comment that says //redraw
08:18 davidre: https://invent.kde.org/qt/qt/qtwayland/-/blob/dev/src/client/qwaylandwindow.cpp#L114
08:19 davidre: ensureSize() calls into updateSurface()
08:23 jadahl: sendExposeEvent() I guess does the drawing and eventually a eglSwapBuffers()?
08:27 davidre: jadahl: I just realized I was following the fractional scale code path and you are talking about buffer scale :D
08:29 jadahl: davidre: it seems to be setting a buffer scale yes, but there is a suspiciously similar thing happening in gtk, and the unique thing that both has in common is the egl implementation
08:30 davidre: I think KWin at the moment is not enforcing it
08:56 pq: dottedmag, probably not for a typical single-person PC desktop. Multiple wl_seat could be used to expose two independent keyboards with different keymaps for eaxmple.
09:11 wlb: weston/main: Alexandros Frantzis * xwayland: Allow shells to make xwayland surfaces fullscreen https://gitlab.freedesktop.org/wayland/weston/commit/ca7b631310ae libweston/desktop/xwayland.c xwayland/window-manager.c xwayland/xwayland-internal-interface.h
09:11 wlb: weston/main: Alexandros Frantzis * xwayland: Notify the shell when a window drops the fullscreen state https://gitlab.freedesktop.org/wayland/weston/commit/b7b0042777c6 libweston/desktop/xwayland.c
09:11 wlb: weston Merge request !1303 merged \o/ (Improve fullscreen handling in Xwayland https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1303)
10:04 dottedmag: pq: I guess it would confuse a heck out of any application if one presesd, say, a Ctrl key on one keyboard and a a letter on another.
10:05 dottedmag: Not a far-fetched situation, actually. Macs with touchbar expose their F-keys as a separate input device, so keyboad (with Fn key) and touchbar have to be in the same seat.
10:47 pq: dottedmag, the "independent keyboards" specifically means they are independent. So pressing Ctrl on one would not affect the other.
10:48 pq: it might confuse end users, or it might be what end users expect - I don't know, because I never use multiple keyboards.
10:48 pq: such a touchbar would arguably not be an independent keyboard, so it would not be exposed in a separate wl_seat
10:50 pq: if all three exist at the same time, I guess there is a judgement call (end user preference) to be made, I guess, which big keyboard gets the touchbar
10:52 pq: ISTR some compositors multiplex multiple keyboards into the same wl_seat by sending a new keymap whenever the end user switches to the other keyboard. That may not support using both keyboards simultaneously either.
13:26 orowith2os: is it just me or does wayland-protocols look like it's been getting a lot more attention recently?
13:26 daniels: a lot more
13:30 emersion: ever since daniels said we need to share a brain
13:31 daniels: haha, in fairness that only came up because there'd already been a huge burst of activity over the past couple/few months
13:57 wlb: weston Merge request !424 closed (Xwayland fullscreen improvements)
14:22 MrCooper: it's good to see, reminds me of the golden age of X development (which is now basically background noise in comparison)
14:24 emersion: drakulix[m]: have you already sent the doodle for the next meeting and i missed it? or not yet?
14:27 drakulix[m]: Not yet, doing that just now.
14:29 emersion: ty
14:34 drakulix[m]: I've not figured out the DKIM-stuff yet though, so it might be flagged again...
14:58 wlb: wayland-protocols Merge request !233 opened by Carlos Garnacho (carlosg) unstable/text-input: Add a .process_keys request https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/233
15:05 wlb: wayland-protocols Merge request !234 opened by Carlos Garnacho (carlosg) unstable/text-input: Add preedit text hints https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/234
19:58 riteo: Hi! I'm working on the wayland port of Godot, a game engine with multiwindow capabilities.
19:59 riteo: I'm aware that there have been discussions (I event participated to them) but I have to ask: in the end, what is the solution we want to take with programs with an occluded main thread bound render loop?
20:00 riteo: I have no idea if this is the right place to ask btw.
20:00 riteo: Basically, I know that there's presentation v2 being worked on, but someone (I think they were named joshua) in the end discarded the idea of zero extents on vulkan
20:01 riteo: I'm asking this because I tried implementing multi windowing anyways and "grabby" xdg_popups being dismissed cause a really weird race condition where the renderer stalls because of the fact that they're destroyed immediately server side
20:03 riteo: This means that godot can't have multi-windowing at all, since not only toplevels can get occluded, but also popups (and they're finnickier overall), stalling everything.
20:04 kchibisov: Are you talking about frame callbacks not being sent for occluded surfaces?
20:04 riteo: yes
20:04 kchibisov: Could godot manage frame callbacks on its own?
20:04 kchibisov: And not rely on vsync of any sort, so nothing gets blocked?
20:04 riteo: I'm not sure, platform code is very very isolated from the rendering code
20:05 riteo: I have no idea how to manually handle frame callbacks.
20:06 kchibisov: So I think your issue is the same as mine in winit, though, our situation is that we don't have any rendering or graphics initialization.
20:07 riteo: what do you mean by no graphics initialization?
20:07 kchibisov: We don't touch OpenGL/vulkan, it's on users.
20:07 kchibisov: unlike libs like glfw.
20:07 kchibisov: And we don't do any drawing at all.
20:08 riteo: oh, godot has some hooks for OpenGL and Vulkan when it comes to initializing both of them and has hooks for calling stuff like swap_buffers on OpenGL
20:08 kchibisov: So, you could ask frame callback before you call swap buffers for example.
20:08 kchibisov: if it's all hooked.
20:08 riteo: mh
20:08 kchibisov: That's whay vsync is doing btw.
20:08 riteo: that wouldn't still fix vulkan
20:08 kchibisov: it simply ask for frame callback and waits for them.
20:09 kchibisov: yeah, you'd need the same hook for vulkan.
20:09 riteo: the issue is that vulkan viewport stuff is actually initialized/cleaned core-side
20:09 riteo: also, wouldn't waiting for the frame callback cause a stall still?
20:09 kchibisov: in winit, for example, we agreed on having a hook on a Window called "pre_present_notify", so users could notify winit about presenting something and winit could schedule frame throttling hint.
20:10 kchibisov: You don't wait, you send a user event back saying that you can draw.
20:10 kchibisov: Once you receive a frame callback.
20:10 riteo: oooh all right
20:10 riteo: we have some "can_draw" getters but I'm not sure they'd be reliable enough
20:10 kchibisov: And you can do the same thing on all platfroms to get non blocking drawing at refresh rate.
20:11 riteo: draw notifications sound like a nice workaround
20:11 kchibisov: I mean you could try your best to provide all the bits for users trying multiwindow, it's not like vsync breaks in single window.
20:11 kchibisov: it's not really a workaround, you have something like that on macOS.
20:11 kchibisov: And Windows.
20:12 kchibisov: On macOS there's a drawRect when the system really wants you to redraw.
20:12 kchibisov: So you have notifications from the OS comming that you must redraw.
20:12 riteo: oh. I'm pretty sure that godot just calls the render loop and if, in the case of Vulkan, it gets null extents it treats the surface as minimized and goes on
20:12 riteo: that's the mess, it relies heavily on the WSI
20:14 kchibisov: it's true that you can use presentation feedback to do manual scheduling on some platforms.
20:14 riteo: actually there's a proposal for presentation v2 which adds a "suspended" state for surfaces
20:14 kchibisov: (e.g. macOS with display link).
20:15 riteo: and the idea is that the WSI could in theory use that to signal minimized windows
20:15 kchibisov: I remember reading about something like that, but it was a long ago.
20:15 kchibisov: It's true that other Oses have Occluded feedback, like macOS/X11.
20:15 riteo: that's what godot expects and that's the mess
20:15 kchibisov: s/Oses/display servers/
20:16 riteo: with X11 it returns whether the window is minimized through WM_STATE_HIDDEN or something named like that
20:16 riteo: with Windows it checks for null extents
20:16 riteo: with MacOS I have no idea :P
20:16 kchibisov: Is godot event driven or it's some sort of regular pumping like a 'real game engine'?
20:17 riteo: yup, it's a dumb loop
20:17 riteo: there's a "window can draw" getter but it's that, a getter
20:17 kchibisov: Yeah, so you likely never targetted anything other than desktops for real.
20:17 riteo: there's also android and ios support
20:17 kchibisov: Oh, but how dump loop handles suspend/resume?
20:18 riteo: I think they just freeze? Lemme check
20:18 riteo: yup
20:18 riteo: "window_can_draw" always return true
20:18 kchibisov: Oh, that's interesting, given that your resources are destroyed and you'll get egl/vulkan errors if you try.
20:19 kchibisov: Though, maybe your loop isn't { collect_events(); do_drawing(); }.
20:21 kchibisov: The issue though, is that you can't really do synchronious event handling like some display systems want.
20:21 kchibisov: like macOS sometimes expects sync reply to events.
20:22 kchibisov: Because 'everything is on the main thread'.
20:24 riteo: that's funny because wayland expects the exact opposite
20:25 kchibisov: writing crossplatform stuff like that is a good way to establish your constant suffering.
20:25 kchibisov:is writing it for 4-5 years...
20:25 riteo:*shrugs*
20:25 riteo: that's the platform port maintainer life ig
20:25 kchibisov: Wayland is the nicest one, because you can tune it to work with everything.
20:27 riteo: ...sort of
20:28 riteo: the grabby popup deletion order is another mess but that's way more manageable than occluded surfaces stalling the renderer or even hardlocking it
20:28 kchibisov: That's just the design you've opted in.
20:28 riteo: not me, I'm new-ish here :P
20:28 kchibisov: you as in godot.
20:29 riteo: oh all right
20:29 kchibisov: If it was event driven you were fine.
20:29 riteo: that said, we do have a single-window mode which works fine enough (ignoring the render loop stalling) but good luck telling users that you can't use the new hyped feature
20:30 riteo: I could try using window_can_draw as a way of signaling drawing but I fear race conditions
20:30 riteo: the wayland event loop is on a thread, the rendering one on another and the compositor is another process entirely
20:30 kchibisov: riteo: frame callback request is sent on surface commit.
20:31 kchibisov: if you commit from rendering thread it'll be fine.
20:31 kchibisov: like you could ask the callback on your main thread, but commit on other thread just fine, because the callback won't be sent until you commit.
20:31 kchibisov: And you commit with swap_buffers/vulkan stuff.
20:32 riteo: oh I see
20:32 kchibisov: that's why we decided to go with `pre_present_notify` hook, so users could simply tell winit to schedule something for them, but the actual delivery is on the user, since they must ask `request_redraw` to get a throttling hint.
20:33 kchibisov: Just ensure when doing that sort of things, with frame callbacks from different thread that commit is entirely on the user.
20:33 kchibisov: Then your can_draw function could align with Wayland common rendering loop, since the users can if (!can_draw()) { continue; }
20:34 riteo: That sounds a pretty good plan, I'm a bit confused on one thing
20:35 riteo: The commit is probably done very close to the method that actually stalls, so we can't rely on _that_ commit. We could commit in `can_draw` but we'd have to do a wl_display_roundtrip and hope that it comes after the roundtrip but I'm not sure that's guaranteed
20:35 riteo: nor by design
20:37 kchibisov: riteo: disable vsync.
20:37 kchibisov: Or not allow users set it on Wayland.
20:38 kchibisov: And instead suggest them to call something like pre_present_notify and signal it from the can_draw().
20:38 riteo: That's doable. Has TEARING support been merged in Mesa? IIRC it hasn't yet
20:39 kchibisov: I've asked the other day and got a reply as 'not yet'.
20:39 riteo: that's a bit of an issue
20:39 kchibisov: The thing is that wayland vsync is different to what you're used to.
20:39 kchibisov: it's the same frame callbacks.
20:40 kchibisov: it's just mesa blocks and waits for them to get back, that's why you have stalling.
20:40 riteo: yeah, but that's because it has no tools to not stall
20:40 riteo: that's the idea with wp_presentation_v2
20:40 kchibisov: Yeah, but the thing is that everything goes through compositor.
20:41 kchibisov: you have tools to not stall, disable vsync.
20:41 riteo: how?
20:41 kchibisov: set_swap_interval(0).
20:41 kchibisov: https://registry.khronos.org/EGL/sdk/docs/man/html/eglSwapInterval.xhtml
20:41 riteo: That's for OpenGL
20:41 riteo: Vulkan is the main dish and it refuses AFAIK
20:41 kchibisov: Don't you have presentation mode similar to that on Vulkan?
20:42 riteo: That's the thing the tearing protocol wanted to fix IIRC
20:42 riteo: and it _has_ been merged, it's the mesa plumbing that hasn't
20:42 kchibisov: Hm, but tearing has nothing to do with how fast you're drawing.
20:43 kchibisov: I can't speak wrt vulkan though, I'm stuck with gles2.
20:43 riteo: oh yeah it wasn't "TEARING", it was "IMMEDIATE" on mesa
20:43 riteo: that's why the name doesn't make sense
20:44 riteo: I recalled it wrong lol
20:44 kchibisov: There's a tearing protocol for wayland, that's what I wanted to say.
20:44 kchibisov: Which can result in real tearing.
20:44 riteo: yeah but it isn't actually plumbed where we need it
20:45 riteo: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18268
20:45 riteo: so it doesn't work yet AFAIK
20:45 kchibisov: But that's not what you actually need though.
20:46 kchibisov: You don't want real tearing, you just don't want your frame rate to be capped.
20:47 riteo: I'm not sure that it can be done
20:47 riteo: the MR I sent you actually adds a case for VK_PRESENT_MODE_IMMEDIATE_KHR
20:47 riteo: which is what we want to not be "capped"
20:47 zamundaaa[m]: What you want is mailbox
20:48 riteo: what does it do?
20:48 riteo: I recall reading that it froze anyways in the three or so MRs that lead to xdg_toplevel suspended and wp_presentation_v2
20:49 zamundaaa[m]: Read https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkPresentModeKHR.html for what the present modes do
20:50 zamundaaa[m]: riteo: toplevel suspension has nothing to do with that
20:51 riteo: yeah ik
20:51 riteo: It was just to clarify the MRs I meant
20:51 riteo: they've been split exactly because of the fact that it has nothing to do with that
20:52 riteo: sorry for the misunderstanding, I know that it has been for some reason a pretty delicate subject, especially after the mesa 1hz MR
20:54 riteo: BTW we do support mailbox. I can try that
21:00 riteo: oh well, it seems to definitely avoid the issue
21:00 riteo: thanks for the tip!
21:03 riteo: I guess that this could be a good enough workaround. I would still like to know the proper way forward though but I suppose I should talk about it in the relevant MR, shouldn't I?
21:03 riteo: Because of the person discarding the proposal for zero extents
21:03 riteo: *null extents
21:05 riteo: anyways, thanks for everything folks! This motivated me further to keep trying to make this work!
21:06 riteo: I think I'll go for now, cya!
22:11 kchibisov: Hw, they left, but there's a 'suspend' on xdg-shell now... Though, frame callbacks are still better.
23:12 orowith2os: kchibisov frame callbacks can be a bit iffy for certain apps, games especially
23:13 kchibisov: you'll use them regardless though.
23:13 kchibisov: Either you or mesa.
23:14 orowith2os: fair, it's just something I've seen come up in quite a few of cases where frame callbacks have caused issues
23:14 kchibisov: And if you don't do vsync you can draw as fast as you can.
23:16 kchibisov: But there's no point to draw as fast as you can though, it's just pointless waste of resources.
23:17 orowith2os: gamers are fuming rn
23:21 kchibisov: Though, frame callbacks are a bit weird when you try to draw with refresh rate lower than the monitor refresh rate.