11:27pq: wl_fixed_from_double()... does it truncate or floor(), and which one is actually right? (Truncation is not right for negative coordinates.)
11:34pq: or should it even be round() to minimize the bias in error
11:58mceier: it doesn't floor, it rounds (0.75/256 converts to 1, 1.5/256 to 2)
12:00pq: hmm, and wl_fixed_to_int() truncates
12:04pq: maybe that explains why I recall seeing a bit of code that did x = wl_fixed_to_int(wl_fixed_from_double(xd));
12:09mceier: oh, the 1 in "converts to 1" in my message is 1/256 if interpreted as wl_fixed...
12:10mceier: wl_fixed_to_int will return 0 for both
12:10pq: yes, I read it that way
12:10mceier: ok
12:11pq: it's just that one functions rounds, and the other truncates - reason? consistency?
12:11mceier: wl_fixed_to_int extracts integer part of wl_fixed
12:12mceier: I'm not really sure what's the problem ;)
12:12pq: negative values
12:13pq: If you truncate, there is a glitch when crossing zero. floor and round don't have that glitch.
12:14pq: The difference between floor and round is an offset of a half integer unit.
12:15pq: Do integer coordinates coincide with the pixel top-left corner or the center? (or the 1/(256×256)th or a pixel)
12:16pq: all these questions stem from Weston migrating from integer to floating-point coordinate systems while still using Pixman regions.
12:17pq: and turns out clamping wl_fixed_t coordinate values has been... not exactly non-decreasing
12:17pq: in Weston, that is
12:21pq: also, wl_fixed_to_int(wl_fixed_from_double(xd)) is different from just casting to int, because there is the rounding to wl_fixed_t in between.
15:25swick[m]: emersion pq libdisplay-info release time?
15:42pq: swick[m], fine by me.
16:28emersion: done! https://lore.kernel.org/dri-devel/eUGSsAPs9QWiofs9rUjNcIffY-PZRaZwsmwUA2NYKBijdqT7cW-4Mv0Lq9k_A6ptlYC8kXnSUV257b-T8AzsfYVJK_MO9shEOyIit_HoU-g=@emersion.fr/T/#u
16:30swick[m]: emersion: nice, thanks!
16:35bl4ckb0ne: does edid-decode have a tagged release?
16:35bl4ckb0ne: (packaging libdisplay-info on alpine)
16:36emersion: doesn't seem like it does
16:36emersion: ah, nice!
16:36emersion: edid-decode is a test-time only dep
16:37emersion: ah, and it's a bit finicky
16:37emersion: you need the exact sha1 as used by libdisplay-info CI
16:37bl4ckb0ne: is it useful beside for testing libdisplay-info?
16:37emersion: so maybe better to disable these tests for a distro…
16:37bl4ckb0ne: sure
16:38emersion: well, yeah, it's useful, it parses more stuff than libdisplay-info atm
16:38bl4ckb0ne: ill package it later then
16:39emersion: maybe we should have a way to disable edid-decode tests
16:39emersion: and leave the rest enabled
16:39bl4ckb0ne: would be nice yeah
16:41bl4ckb0ne: got a couple of warning when building, want me to open an issue?
16:41emersion: what kind of warnings?
16:41emersion: can you pastebin these?
16:41emersion: but yeah these generally should be fixed
16:43bl4ckb0ne: https://paste.sr.ht/~bl4ckb0ne/c6d9926c7c65a59a2ad47e0e655faf37c527b4a3
16:52emersion: ah yes, i've seen that one before i think…
16:53bl4ckb0ne: they only pop in the package build
16:54bl4ckb0ne: alpine pkg available on edge
16:57emersion: that was fast :)
16:57bl4ckb0ne: always
16:57bl4ckb0ne: let me know when things get better with the test stuff
16:57emersion: please do open an issue
16:58bl4ckb0ne: sure
17:13emersion: bl4ckb0ne: the warnings are unrelated to edid-decode
17:13emersion: can you open a separate issue for the warnings?
17:14emersion: (your link in the issue about edid-decode points to the warnings)
17:18_DOOM_: I am having trouble with the xdg_output protocol. Where the names for outputs are have strange characters that can't be read.
17:18_DOOM_: I'm not really sure what the issue is.
17:20emersion: ah apparently some people package it for debian even before the first release https://packages.debian.org/bookworm/source/libdisplay-info
17:20emersion: and in gentoo too
17:20bl4ckb0ne: arch too
17:22emersion: nah, just in the AUR
18:35emersion: pq, daniels, jadahl: would that wayland release calendar be fine for you? https://paste.sr.ht/~emersion/656baca014616d0c2502127c555b9886539348ec
18:35emersion: gives some time to review/merge
18:36emersion: i really think we should stop with the alpha/beta releases though
18:42daniels: lgtm, but yeah without distros meaningfully testing/shipping/etc I don’t see too much point in alpha/beta
18:43wlb: wayland Merge request !293 opened by Simon Ser (emersion) releasing: update and convert to Markdown https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/293
18:44wlb: wayland Issue #354 opened by Simon Ser (emersion) Drop alpha/beta from release process https://gitlab.freedesktop.org/wayland/wayland/-/issues/354
18:47emersion: ouch https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3994#note_1771257
18:47emersion: we messed up the .pc file it seems
18:58wlb: wayland Merge request !294 opened by Simon Ser (emersion) readme: update and convert to Markdown https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/294
19:02jadahl: emersion: no objections about the schedule from me
19:43DodoGTA: So is there a way to prevent the Wayland socket buffer from filling up in Wayland apps? 🐸️
19:47jadahl: DodoGTA: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188
19:54DodoGTA: Finally I found a report for my mysterious issue: https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
20:01wlb: wayland Issue #355 opened by Victor G (VictorGimenez) Simulate/automate mouse and keyboard events https://gitlab.freedesktop.org/wayland/wayland/-/issues/355
22:38nullpointer128: Hey all, I'm thinking about making a new protocol and I was wondering if there is any standard for a sort of "wl_mask" style data type?
22:39nullpointer128: I was thinking of using a wl_buffer the same width and height of the wl_surface's buffer, but it only has one channel
22:51nullpointer128: Something like wl_surface_get_mask(id: new_id<wl_surface>, surface: object<wl_surface>)?