08:10 wlb: wayland-protocols Issue #224 opened by () ext_image_copy_capture_session_v1 should have an event to communicate the "native" format https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/224
08:33 wlb: weston/main: Jeri Li * libweston/desktop: avoid weston crash while xdg_surface ack_configure https://gitlab.freedesktop.org/wayland/weston/commit/04f27f1be2e0 libweston/desktop/ xdg-shell-v6.c xdg-shell.c
08:33 wlb: weston Merge request !1624 merged \o/ (xdg_surface: avoid weston crash while xdg_surface ack_configure https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1624)
10:17 wlb: weston Issue #956 closed \o/ (Panel dissappears after blanking https://gitlab.freedesktop.org/wayland/weston/-/issues/956)
10:17 wlb: weston/main: Marius Vlad * desktop-shell: Don't attempt to re-add the view to panel layer https://gitlab.freedesktop.org/wayland/weston/commit/217fb308471b desktop-shell/shell.c
10:17 wlb: weston Merge request !1619 merged \o/ (desktop-shell: Don't attempt to re-add the view to panel layer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1619)
10:36 wlb: weston Merge request !1625 opened by () Weston 14.0.1 fixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1625
11:25 arthuro555: Hey, I noticed my HDMI devices were reporting as having keyboard and pointer capabilities when running `libinput list-devices`. I was wondering if there's a way to disable these capabilities? I tried ignoring the devices with udev rules, but that prevents my wayland compositor from rendering to the screen as well :/
11:34 bl4ckb0ne: if it has buttons its a keyboard
17:59 daniels: https://meet.x.org/xdc2024-wayland for the XDC workshop
18:00 daniels: can one of you try speaking please?
18:16 wlb: wayland-protocols/main: Simon Ser * governance: drop adoption website section https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/9e5b8a4e9a35 GOVERNANCE.md
18:17 wlb: wayland-protocols Merge request !314 merged \o/ (governance: drop adoption website section https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/314)
18:42 wlb: wayland-protocols/main: Derek Foreman * fifo-v1: Add new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/1ccc5748acc2 staging/fifo/README staging/fifo/fifo-v1.xml meson.build
18:42 wlb: wayland-protocols Merge request !256 merged \o/ (fifo-v1: Add new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256)
18:49 wlb: wayland-protocols/main: Derek Foreman * commit-timing-v1: Add new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/37a1560cf698 staging/commit-timing/README staging/commit-timing/commit-timing-v1.xml meson.build
18:49 wlb: wayland-protocols Merge request !248 merged \o/ (commit-timing-v1: Add new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/248)
19:03 llyyr: congrats
20:27 wlb: wayland-protocols Merge request !350 opened by () build: Bump version to 1.38 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/350
20:41 mclasen: jadahl: looking through universally implemented protocols, I stumbled over relative-pointer, which is still unstable, after 7 years of not touching it
20:41 jadahl: mclasen: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/252
20:43 llyyr: is there a way a client can know if the user's mesa implements fifo-v1? I know SDL2 checks if the compositor advertises it, but doesn't it require the mesa implementation to go with it as well?
20:45 mclasen: jadahl: looks stalled
20:47 mclasen: but good to see, anyway
20:52 jadahl: mclasen: one of the governence MRs addresse that
21:15 Eighth_Doctor: 🎉
21:34 misyl: llyyr: It does require that, but there wasn't a nice way there.
21:50 llyyr: what about nvidia? does nvidia implement this in their WSI?
21:51 llyyr: mpv currently uses mailbox, but would prefer to use fifo if fifo-v1 works on the system but there doesn't seem to be any way to actually check if the WSI facilitates this or not
21:58 misyl: I am curious, why would MPV want fifo?
22:00 wlb: wayland-protocols Merge request !320 closed (presentation-time: Specify refresh bounds for VRR)
22:02 llyyr: misyl: why would a video player not want vsync blocking? mpv currently uses mailbox and tries to block itself by trying to predict the next vblank using wp_presentation_feedback
22:02 llyyr: this works fine, but instead of emulating fifo it would be better to just pick fifo instead
22:19 misyl: I was more thinking about eg. scrubbing and not wanting to delay that with the queued up frame(s)
22:21 wlb: wayland-protocols/main: Daniel Stone * presentation-time: Specify refresh bounds for VRR https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/8cdb39103247 stable/presentation-time/presentation-time.xml
22:21 wlb: wayland-protocols Merge request !320 merged \o/ (presentation-time: Specify refresh bounds for VRR https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/320)
22:23 llyyr: mpv has presentation modes where it tries to sync the video to the display, and resample the audio to match the video (instead of timing video frames to audio and not assume anything about the display), so a vsync blocked presentation mode is required for that
22:24 daniels: yeah, it just wants to queue up frames ahead of time and not have to second-guess the compositor
22:24 misyl: gotcha
22:24 misyl: makes sense
22:24 llyyr: in general, repeated or dropped frames are much worse than frame latency
22:24 daniels: but, like, not so many frames that you shoot yourself in the foot when you’re seeking or pausing