07:57 MrCooper: Delicates: FWIW, the colour depth seen by the monitor doesn't directly correspond to the pixel format of the framebuffer scanned out by the GPU; there's a colour processing pipeline which generally always outputs more than 10 bits per component with non-ancient GPUs
08:21 wlb: wayland Issue #522 opened by Thomas Klausner (wiz) make header C++ safe https://gitlab.freedesktop.org/wayland/wayland/-/issues/522
09:26 pq: Delicates, I'd trust the monitor Service Menu. Understanding what it says is another matter, I wouldn't know what 244 or 10000 refer to. However, 10-bit depth is theoretically independent of SDR vs. HDR.
09:28 JEEB: yea, and that is also what there is in reality. after all, 10bit connections were a thing before the colorspace configuration stuff got added
09:28 JEEB: (or trc stuff)
09:30 JEEB: also why the 10bit mode in windows/d3d started existing before the color related memorabilia :) (and most likely in DRM/x11/wayland as well)
09:48 MrCooper: you're again mixing up framebuffer pixel format and display link bpc
09:49 JEEB: ah
09:53 MrCooper: (sorry, pet peeve of mine :)
10:07 narodnik: in keyboard_handle_key(), i get a key: u32. I'm trying to handle repeated keys (when holding a key down). but i get key=73 'I' state=1, then release shift, then the key and i get key=105 'i' state=0
10:08 narodnik: how do I detect these are synonyms of each other?
10:08 narodnik: like how can i remove modifiers from a key?
10:10 narodnik: oh wait nvm, it's my fault
10:28 kennylevinsen: narodnik: you're looking at the decoded keysym, not the keycode
10:29 kennylevinsen: What you receive for a wl_keyboard in that sequence is key: 50 state: 1 (shift), key: 31 state: 1 (which is *sym* 73 for 'I'), key: 50 state 0 (release shift), key 31 state 0 (release 'i')
10:30 kennylevinsen: assuming a US layout
10:30 narodnik: amazing ty, i applied that fix exactly
10:30 narodnik: https://github.com/not-fl3/miniquad/pull/515
10:31 kennylevinsen: yup
11:27 wlb: weston Merge request !1672 opened by kang-sooyeon (kang-sooyeon) libweston/input.c: Fix weston crash with the mouse event https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1672
12:44 vyivel: seems like zwp_pointer_gesture_swipe_v1 is not enough for setups with multiple touchpads
13:00 davidre: Why is that?
13:16 wlb: weston/main: Leandro Ribeiro * 9 commits https://gitlab.freedesktop.org/wayland/weston/compare/a2dba7ff0001bae4ea67bd470ca631222df2780b...eabc19bc3b85703b97ea654a7e48f361e65805b0
13:16 wlb: weston Merge request !1621 merged \o/ (Fix dma-buf feedback issue https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1621)
13:19 vyivel: davidre: a gesture object can only notify of one active gesture of a specific type at a time
13:19 vyivel: i.e. swiping on multiple touchpads at the same time can't be relayed to a client properly
13:20 vyivel: …not that it's a very important case to handle though
14:17 zamundaaa[m]: vyivel: it's tied to wl_pointer
14:18 zamundaaa[m]: so you can support multiple touchpads being used at the same time as well as you can support multiple pointers - each on a different seat
14:19 vyivel: sure, even though "[t]he wl_pointer interface represents one or more input devices"
18:33 soreau: does weston handle gpu resets at all? would patches be accepted for relevant weston clients to survive gpu resets?
18:34 daniels: soreau: we'd take them for clients for sure - the compositor-side support is under review atm
18:35 soreau: daniels: nice, thanks