03:00 <dos1> is there some documentation available on wl_egl_window_resize behavior? i.e. whether there are situations where the next commit will still have a buffer with old size attached etc.

08:26 <pq> dos1, sorry, I don't recall there being any, that is a very good and tricky question.

08:26 <pq> dos1, I believe the size is "locked" for the next swapbuffers by any API call that needs to allocate a buffer.

08:27 <pq> dos1, so not just GL drawing calls, but also things like querying buffer_age extension.

09:28 <emersion> daniels, pq: ack/nack? https://paste.sr.ht/blob/dc6591e148bc66827f2818a4b86aaa17d797565f

09:28 <emersion> for weston 10.0

09:48 <pq> emersion, sounds good to me. I'll be back on Aug 26 from holidays, and I have nothing I specifically want landed for this release.

09:51 <dos1> should the dimensions obtained from wl_egl_window_get_attached_size right before calling eglSwapBuffers always match the commited buffer size?

09:51 <daniels> emersion: generally sounds good to me, but I would like to see dmabuf-hints land rather than postpone it all another few months ... leandrohrb2 do you have any thoughts about that?

09:52 <daniels> dos1: no

09:52 <daniels> dos1: wl_egl_window_get_attached_size() will return the dimensions of the buffer committed the _last_ time you called eglSwapBuffers

09:52 <dos1> I see

09:52 <dos1> is there a way to find out what size is going to be commited?

09:53 <daniels> if you want to see what's going to get committed the _next_ time you call eglSwapBuffers, call eglQuerySurface(surf, EGL_{WIDTH,HEIGHT})

09:53 <dos1> thanks!

09:54 <daniels> as pq says, resize requests take effect the first time in a frame that you need a new buffer - after you call eglSwapBuffers there is no current back buffer, until you do something like submit a GL draw call or query EGL buffer age, which would cause a back buffer to be locked - the resize request takes effect during that lock

09:56 <pq> daniels, and we seriously still have no docs about this anywhere?

09:57 <dos1> yeah, I get that. the thing is that SDL doesn't control whether the client has issued some GL calls already or not at the time wl_egl_window_resize is called, so it needs to find out whether the resize request took effect already or not in order to know when to ack the configure request

09:58 <dos1> but sounds like eglQuerySurface will do

09:58 <pq> dos1, is there no other way to go about it? You can't e.g. ensure to call wl_egl_window_resize() right *before* eglSwapBuffers of the *previous* frame? Maybe you don't have the new size yet at that time?

10:00 <pq> I'm just thinking that there should be a more explicit way to match window state with the content drawn, because resizes are not the only thing that might change.

10:06 <daniels> pq: well, it depends on your definition of 'anywhere' :P https://lists.freedesktop.org/archives/mesa-dev/2018-June/thread.html#196474

10:08 <pq> daniels, add that link in the EGL_KHR_platform_wayland spec?

10:09 <dos1> I'm afraid SDL client API isn't really in the "every frame is perfect" age yet. AFAIK the client doesn't even have a way to acknowledge the resize back to SDL

10:10 <dos1> or any other state change for that matter

10:11 <pq> dos1, does that mean that apps don't check what the window state should be before they draw? If they did, couldn't SDL assume that if the state update is visible to the app, the next frame will be drawn accordingly? I guess this breaks on threaded apps?

10:15 <dos1> apps receive events, like SDL_WINDOWEVENT_RESIZED with new window dimensions - but clients can still draw and flip buffers in between the points of time when the event has been queued by SDL and handled by the app

10:17 <dos1> the resize used to be delayed until after wl_egl_window_resize (that's how I wrote it back in 2018), but apparently it was causing troubles with clients that only draw opportunistically: https://github.com/libsdl-org/SDL/issues/4326

10:23 <pq> dos1, and I think there is also slack betweend "handled by the app" and "actually drawn by the app", so yeah.

10:29 <dos1> blah, until after eglSwapBuffers*

10:38 <wlb> wayland Merge request !163 closed (gitlab-ci: add a FreeBSD test job)

11:21 <dos1> I must be still missing something - I check with eglQuerySurface whether it has the new size already; if so, then call ack_configure; and then call eglSwapBuffers

11:21 <dos1> I still end up with a buffer of the old size commited after ack_configure

11:21 <dos1> which weston then rejects with wl_display@1.error(xdg_wm_base@13, 4, "xdg_surface buffer (1280 x 720) is larger than the configured fullscreen state (640 x 480)")

11:36 <wlb> weston Merge request !672 opened by Sebastian Krzyszkowiak (dos) xdg-shell: Rephrase the "geometry larger than fullscreen state" error https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/672

11:44 <wlb> weston/main: Sebastian Krzyszkowiak * xdg-shell: Rephrase the "geometry larger than fullscreen state" error https://gitlab.freedesktop.org/wayland/weston/commit/ce2fa93a6e2b libweston-desktop/xdg-shell.c

11:45 <wlb> weston Merge request !672 merged \o/ (xdg-shell: Rephrase the "geometry larger than fullscreen state" error https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/672)

11:52 <wlb> weston Issue #525 closed \o/ (Weston failure with external monitor connected and DRM backend https://gitlab.freedesktop.org/wayland/weston/-/issues/525)

12:07 <dos1> so, based on my current understanding of how it all should work this doesn't make much sense: https://paste.debian.net/1206328/

12:12 <dos1> running this on a compositor that doesn't throw an error in that case shows that the next frame gets a new and correctly sized buffer

12:12 <pq> dos1, I agree... there are two things missing: EGL creating a new wl_buffer in the new size which seems like the resize didn't go through; the other is lack of adjusting xdg_surface geometry but if the client never set that maybe it's supposed to be automatic from surface size.

12:13 <dos1> geometry was never set

12:13 <pq> ok

12:14 <pq> so yeah, something is going wrong with the resizing, and I don't remember the intended semantics between all those EGL-related calls to say anything

12:15 <pq> a Mesa bug is not impossible either I suppose, if other compositors don't bother with errors

12:16 <dos1> yeah, from all the compositors I tried only weston checked for this error

12:16 <pq> nor is a Weston bug, but since no new wl_buffer is seen created, I'd think it's something client-side

12:18 <pq> dos1, if you don't get help here, I'd suggest filing a Mesa bug.

14:42 <wlb> weston Merge request !673 opened by Marius Vlad (mvlad) desktop-shell: Use weston_surface_destroy() directly https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/673

15:24 <mriesch> pq, may i ask what happened to your call for an edid parsing library? did you agree on some basis project to build on?

15:26 <emersion> mriesch: https://github.com/contactshashanksharma/libedid/

15:27 <emersion> and then died out i guess

15:27 <emersion> fwiw, i don't really agree with pq about libedid design

15:27 <emersion> i think an edid lib shouldn't be opinionated

15:27 <emersion> or else should be called something else

15:27 <emersion> like libedidforasingleusecase :P

15:28 <mriesch> emersion: yay, thanks for the link. and oooh, only one commit :-/

15:29 <emersion> it's one of these cases where the cost of adding a new dep is greater than just copy-pasting the few 100s of LoC

15:30 <mriesch> opinionated with regards to what exactly?

15:31 <mriesch> design of the api?

15:31 <emersion> pq iirc suggested that the edid lib would only take care of extracting data for wayland compositors

15:31 <emersion> so only make/model/serial and HDR/colorimetry stuff likely

15:34 <mriesch> ah ok

15:55 <plaes> most advanced one I know is this one: https://git.linuxtv.org/edid-decode.git

15:55 <plaes> ..but it's not a library

16:02 <mriesch> plaes, thanks! this project was mentioned in the discussion in april. i was wondering whether there was any attempt to separate it in a library and an executable

23:21 <wlb> wayland.freedesktop.org/main: Peter Hutterer * libinput 1.18.1 release https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/860083beed06 libinput/doc/ 1.18.0 1.18.1/.buildinfo 1.18.1/_images/button-debouncing-wave-diagram.svg 1.18.1/_images/button-scrolling.svg 1.18.1/_images/clickfinger-distance.svg 1.18.1/_images/clickfinger.svg 1.18.1/_images/edge-scrolling.svg 1.18.1/_images/gesture-2fg