01:29 <NepNepdmsalwaysopen[m]> Hello! I'm working on implementing hyprland_toplevel_export_v1, using handles from zwlr_foreign_toplevel_manager_v1 to indentify toplevels in capture_toplevel_with_wlr_toplevel_handle (part of the first protocol). Since I'm new to wayland development and using zig-wlroots/zig-wayland, there's something I haven't been able to figure out yet: The request data includes a pointer to the server.zwlr.ForeignToplevelHandleV1 of

01:29 <NepNepdmsalwaysopen[m]> the toplevel it wants to capture, that handle type is automatically generated by the zig-wayland build system, but the handles stored in the compositor I'm working on (river, though I'm forking it rather than making a PR since as far as I know the maintainer wants to wait for a standard way to do it) are stored as the zig-wlroots version, which isn't automatically generated, what I don't know is how to compare them.

08:17 <any1> NepNepdmsalwaysopen[m]: What does hyprland_toplevel_export_v1 do?

08:17 <any1> Nm, I found it. :)

08:20 <any1> Looks like screencopy for toplevels.

08:33 <kennylevinsen> NepNepdmsalwaysopen[m]: a normal use of these would be to attach some data to the handle where it is created, which can then be referenced whenever a call is made using that object

08:33 <kennylevinsen> for the wlroots implementation, wlr_foreign_toplevel_handle_v1 has a data pointer you can attach anything to

08:34 <kennylevinsen> this can in turn be referenced in the hyprland_toplevel_export_manager_v1.capture_toplevel_with_wlr_toplevel_handle handler

09:13 <pq> emersion, re: VKMS configfs; Yay! \o/

09:57 <wlb> weston Issue #765 opened by binzhai (binzhai) The screenshot function under weston will cause a black screen https://gitlab.freedesktop.org/wayland/weston/-/issues/765

10:09 <pq> another set of the same freebsd flake in https://gitlab.freedesktop.org/lpique/wayland/-/pipelines/916409

10:09 <emersion> tbh maybe we should just disable this test under freebsd

10:10 <emersion> in general i'm not a big fan of hacks like these

10:10 <pq> how would you test them instead?

10:11 <emersion> the way you'd do in other languages where such hacks are not possible in the first place

10:12 <emersion> e.g. via a function pointer which can be modified by the test

10:12 <pq> I don't think I'm familiar with that at all.

10:13 <emersion> yes, it may decrease PeRFoRmAnCe a bit :P but who cares

10:13 <pq> I'm not worried about performance.

10:14 <emersion> i'll try to put up a MR, and you can tell me how you feel about it

10:14 <pq> if it is what I'm guessing it is, it mostly depends how you are going to expose those vfuncs for modification

10:18 <emersion> pq: something like this https://paste.sr.ht/~emersion/bcc5864987624b3026ffeb214959ca1063d34293

10:19 <pq> right, that's the part that I guessed and is fine by me.

10:22 <psykose> in what way does that decrease performance

10:25 <pq> good question, they are library calls to begin with

10:25 <emersion> maybe libc has it static inline in a header or something

10:25 <emersion> or maybe libc has clever LTO stuff

10:26 <pq> if it did, we couldn't override them like we do?

10:26 <emersion> hm, that's true…

10:26 <emersion> hm, and the LTO is not possible

10:27 <emersion> LTO is just inside a single .so

10:27 <emersion> so yeah, probably doesn't matter anyways

10:27 <emersion> i guess LTO _could_ happen if you statically link libc

10:28 <pq> I'm more worried about having two vfuncs for the same thing, one in libwayland-server and one in libwayland-client, and those somehow getting mixed up by e.g. the tests trying to modify them.

10:30 <pq> the build of 'test_runner' links curiously many things...

10:31 <kennylevinsen> emersion: if you statically link libc I assume you also want to statically link libwayland, and then you get all the LTO

10:31 <emersion> pq, wouldn't these share the same wayland-os.o?

10:31 <emersion> hm

10:31 <pq> oh right, os-helpers are explicitly linked statically, so they can be tested, since none of them are exported

10:33 <pq> emersion, it doesn't reduce duplication if the same .o is copied into two .so

10:33 <emersion> yea

10:33 <pq> but I think it should be just fine - don't export anything

10:34 <pq> the test will be testing its own copy of the .o, not going through the .so

10:37 <wlb> wayland Merge request !325 opened by Simon Ser (emersion) Draft: tests: manually wrap fcntl() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/325

10:38 <emersion> well, this doesn't work and no idea why

10:43 <pq> does moving the init_fallbacks() after the overriding functions matter?

10:44 <pq> I've no idea, just wildly guessing

10:45 <emersion> nope, same errors

10:47 <pq> the messages about test-runner.c:373 and test-runner.c:379 seem totally bogus

10:47 <emersion> it's UBSan

10:48 <pq> like dynamic linker was trying to load something into a garbage address

10:48 <emersion> ah, they also happen on main

10:48 <emersion> so they are red herring

10:54 <emersion> oh, i just didn't take enough tea this morning

10:55 <emersion> init_fallbacks() needs to always wrap all functions

11:22 <wlb> weston Issue #626 closed \o/ (Screen capturing https://gitlab.freedesktop.org/wayland/weston/-/issues/626)

12:03 <wlb> weston/main: Daniel Stone * build: Switch join_paths(foo, bar) to foo / bar https://gitlab.freedesktop.org/wayland/weston/commit/386dcd904fda compositor/meson.build data/meson.build doc/sphinx/meson.build libweston/meson.build man/meson.build meson.build

12:03 <wlb> weston/main: Daniel Stone * build: Run tests with leak-sanitizer suppressions https://gitlab.freedesktop.org/wayland/weston/commit/249f68adb0da meson.build tests/meson.build

12:03 <wlb> weston/main: Daniel Stone * CI: Remove per-test-asan wrapper https://gitlab.freedesktop.org/wayland/weston/commit/68fd41a719ef .gitlab-ci.yml .gitlab-ci/virtme-scripts/run-weston-tests.sh .gitlab-ci/virtme-scripts/per-test-asan.sh

12:03 <wlb> weston Merge request !1281 merged \o/ (build: Run tests with leak-sanitizer suppressions https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1281)

12:19 <wlb> weston Issue #764 closed \o/ (gl-renderer: Vertex clipping optimizations break rendering of rotated clients https://gitlab.freedesktop.org/wayland/weston/-/issues/764)

12:19 <wlb> weston/main: Loïc Molinari * gl-renderer: Make clip_transformed() surf parameter constant https://gitlab.freedesktop.org/wayland/weston/commit/edd5d1cc0912 libweston/ vertex-clipping.c vertex-clipping.h

12:19 <wlb> weston Merge request !1283 merged \o/ (gl-renderer: Make clip_transformed() surf parameter constant https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1283)

13:42 <emersion> pq, re !325, should i also do the same for other functions?

13:49 <wlb> weston/main: Philipp Zabel * gl-renderer: clear renderer pointer in gl_renderer_destroy https://gitlab.freedesktop.org/wayland/weston/commit/da683dad577e libweston/renderer-gl/gl-renderer.c

13:49 <wlb> weston/main: Philipp Zabel * backend-wayland: fix error path in wayland_backend_create https://gitlab.freedesktop.org/wayland/weston/commit/47180ad25312 libweston/backend-wayland/wayland.c

13:49 <wlb> weston Merge request !1279 merged \o/ (backend-wayland: fix error path in wayland_backend_create https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1279)

14:16 <pq> emersion, sure, I was already expecting that you wanted to remove all the dlsym trickery completely :-)

14:16 <emersion> for sure :)

15:53 <wlb> weston/main: Daniel Stone * 20 commits https://gitlab.freedesktop.org/wayland/weston/compare/47180ad25312d1dea478ae825abadf56f425a511...0a4d74c60d44a3c2309253a25a9871facf045920

15:53 <wlb> weston Merge request !1276 merged \o/ (Add helper for moving views on and off layers https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1276)

16:20 <wlb> weston Merge request !1284 opened by Derek Foreman (derekf) toy-toolkit: Fix rotations https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1284 [Toytoolkit]

23:38 <swick[m]> pq: https://www.nhk.or.jp/strl/english/publica/giken_dayori/205/1.html

23:38 <swick[m]> https://youtu.be/ZhkbzNHWf0Q?t=1213