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