09:54 <wlb> weston Issue #619 opened by () Update of absolute positions in Tk windows not working with Xwayland (Menu opened at wrong location) https://gitlab.freedesktop.org/wayland/weston/-/issues/619

10:03 <daniels> pq: is 'sounds good' on !844, 'great you can click merge', or 'nice but let me take a look'? :)

10:24 <daniels> pq: ooh wait let me fix the bpp assignment first; I thought I did already!

10:28 <pq> daniels, "let me take a look" because it seems every round adds something :-p

10:29 <pq> or drops a good patch

10:40 <pq> daniels, another review round done.

10:58 <daniels> pq: another push!

11:06 <daniels> sorry for dropping the good patch, I forgot that was in the clean-for-MR section rather than the possibly-terrible-cleanup-experiments section

11:28 <wlb> weston Merge request !844 merged \o/ (gl-renderer: Handle SHM formats much more generically https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/844)

11:28 <wlb> weston/main: Pekka Paalanen (pq) * 20 commits https://gitlab.freedesktop.org/wayland/weston/compare/297ad403d6e4416c9fc969cce316832947dd8fd4...dfaba9f107360d512b3bd0dd9ed4c710812d0126

12:17 <daniels> pq: thanks :)

12:37 <wlb> weston Merge request !868 opened by () rdp: Make thread checks unconfigurable https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/868 [RDP backend]

15:20 <ifreund> I've been doing some experimentation with my zig wayland scanner recently and have started enforcing the "object creation hierarchy must be a tree" thing with exceptions for wl_callback and wl_buffer

15:21 <ifreund> I think it would be cool if there was some attribute in the xml to indicate that the version of an interface is fixed at 1 and it is safe to break normal object creation hierarchy rules

15:22 <ifreund> then I could get rid of my hardcoded list and perhaps wayland-scanner could also start erroring out on broken things like zwp_input_method_context_v1.grab_keyboard

15:23 <ifreund> another interesting thing zig-wayland now does is require the user to specifiy a fixed version for which to generate code for each global at build time

15:24 <ifreund> this is for API forward compatibility reasons, but it also gets used in the wl_registry_bind() equivalent to fix the most common forward compatibility client bug I've seen in the wild

15:25 <ifreund> namely passing a higher version than the client supports to wl_registry_bind()... zig-wayland clamps it to the version of the code it generated

17:02 <mahkoh> hi. is the linux-explicit-synchronization protocol required for a wayland compositor to work properly (flicker free, no corruption) on the proprietary nvidia driver? I'm mostly interested in pure-wayland clients, xwayland is another issue.

17:04 <mahkoh> unfortunately I have no nvidia hardware to test this

17:22 <LaserEyess> explicit-sync is not required for any wayland compositor

17:22 <LaserEyess> or client, for that matter

17:29 <mahkoh> I understand that explicit-sync is not a required extension. But I'm also aware that there are problems with xwayland on nvidia because the nvidia driver does not implement implicit sync and xwayland does not provide them with a way to work around this. that's what makes me believe that there might also problems with pure wayland applications if the server does not offer the explicit-sync extension of the nvidia dri

17:29 <mahkoh> *for the nvidia driver to use

17:30 <mahkoh> I can also imagine that the nvidia egl and vulkan drivers work around this by delaying client side until all rendering is done. but I would like to know for sure.