09:41 wlb: weston/main: Pekka Paalanen * 13 commits https://gitlab.freedesktop.org/wayland/weston/compare/43f7b7b3bb02935417e41c43c8e3ce921e011eee...c01a1f7c641ae4c44a1fb835082c4e31024e4e18
09:41 wlb: weston Merge request !1502 merged \o/ (Implement the CM&HDR protocol mechanics to support clients that want to create cprof from params https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1502)
12:22 pq: emersion, I wonder if libdisplay-info should have a custom assert that cannot be disabled. I imagine many might have the idea of categorically disabling asserts when building for production.
12:24 vyivel: NDEBUG was a mistake
12:24 emersion: or just refuse to build with NDEBUG?
12:26 pq: that might work, weston test suite does that
12:27 emersion: libdisplay-info test suite also does that iirc
12:27 pq: weston is slowly migrating to a custom assertion API as well, so that it can print actual values rather than just the expression.
12:28 emersion: i see
12:30 pq: evidently someone managed to try to build libdisplay-info with NDEBUG, and that particular assert was surprisingly harmless to skip, as long as developers don't test with NDEBUG.
13:25 mceier: "assert that cannot be disabled" is just an error path. maybe libdisplay-info is misusing asserts.
13:33 emersion: i dont think it depends on asserts being enabled
13:33 emersion: still, I don't really like having them toggleable
13:38 pq: mceier, an error path from which there is no sensible recovery possible.
13:40 MrCooper: abort()?
13:42 pq: yeah
14:16 emersion: i think i've used abort() in these places
14:16 emersion: i never use assert(0)
14:16 kchibisov: library should generally never abort.
14:18 kchibisov: Unless you want to use abort instead of assert to guide how to use library, but it really sounds like you want to save on errors.
14:20 kchibisov: but e.g. crashing compositor instead of error for something that won't really make a difference (likely) is probably a bit too much.
14:20 emersion: abort() marks unreachable code
14:21 kchibisov: though, if the code can not be reached then it won't be executed, so what you place there won't matter.
14:27 pq: kchibisov, yes, I think we know the difference.
14:30 soreau: it's the code executed before the assert that matters.. I've found debugging is more difficult when hitting an assertation - usually have to modify the source
14:43 narodnik: when i get wl_keyboard_leave, i clear all key repeats. should i also clear all modifier keys too?
14:45 soreau: you can get modifiers down on keyboard enter, FWIW
14:45 soreau: but it probably depends on your specific case what you want to do
14:46 narodnik: well right now if i press super to leave the window, then when i come back, it thinks super is still pressed
14:50 soreau: and if you clear on leave, there's a different problem?
14:52 narodnik: no, i was just wondering if that's the correct thing to do
14:52 soreau: I guess you might want to mark mods down if any are actually pressed on enter..
14:53 any1: You always get the modifiers right after enter. It's in the spec. Just clear on leave
14:53 soreau: I think wev might have the code to get the mods on enter
14:53 pq: https://wayland.app/protocols/wayland#wl_keyboard:event:modifiers - sounds like the modifiers event *sets*, not updates, the state.
14:54 pq: as in, it's the full new state, not a diff
14:55 pq: that doc also covers modifiers for pointer events
14:58 pq: just mentioning in case there was confusion on how to handle that
15:28 zamundaaa[m]: pq: about the color management protocol, do we now accept the test app for the one feature?
15:28 zamundaaa[m]: If so, I could just update a few v4 implementations against the current version of the protocol, and it would be ready for merging
16:01 pq: zamundaaa[m], let's talk about that tomorrow. I've also one little break suggested for the protocol in the TF enum, waiting for comments.
16:05 pq: ah, you reviewed exactly that, thanks.
16:05 pq: anyway, tomorrow