04:36 wlb: wayland-protocols Merge request !298 opened by Peter Hutterer (whot) Draft: tablet: add support for relative dials https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/298
06:43 wlb: weston Merge request !1500 merged \o/ (tests: Call open() with the right flag https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1500)
06:44 wlb: weston/main: Emmanuel Gil Peyrot * tests: Call open() with the right flag https://gitlab.freedesktop.org/wayland/weston/commit/677025966be6 tests/color-management-test.c
08:38 wlb: weston/13.0: Jeffy Chen * renderer-gl: Fix wrong stride error when reading pixels https://gitlab.freedesktop.org/wayland/weston/commit/b49856fe53b9 libweston/renderer-gl/gl-renderer.c
08:38 wlb: weston/13.0: Derek Foreman * gl-renderer: apply output transform before readback in repaint https://gitlab.freedesktop.org/wayland/weston/commit/d82762e6b7b1 libweston/renderer-gl/gl-renderer.c
08:38 wlb: weston Merge request !1493 merged \o/ (Backport some gl-renderer fixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1493)
08:43 jumpingAI: we saw lot's of birtish trash scout boys who demonstrated their non-existent amoeba one brain cell skills to their ladies like The crook Dave Airlie , we deliver them in coffin to the last road soon, planted another biochip to harvest testosterone, i am aware of this again, they get opted for removal before i join billionaire club, The British human garbage
08:43 jumpingAI: ouh my word
08:43 jumpingAI: extraordinary shit
08:45 dwfreed: .
08:52 wlb: weston Issue #843 closed \o/ (Gstreamer waylandsink sometimes not showing. https://gitlab.freedesktop.org/wayland/weston/-/issues/843)
08:53 wlb: wayland-protocols Issue #191 opened by Julian Orth (mahkoh) Cross-protocol versioning https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/191
09:01 wlb: wayland-protocols Issue #191 closed \o/ (Cross-protocol versioning https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/191)
09:21 wlb: wayland Merge request !330 closed (scanner: specify enum underlying type for C23)
09:24 wlb: wayland-protocols Merge request !12 closed (virtual-pointer: introduce new protocol)
10:36 wlb: wayland Issue #455 opened by Daniel Stone (daniels) Clarify if parent commit is required when subsurface becomes mapped https://gitlab.freedesktop.org/wayland/wayland/-/issues/455 [Protocol]
10:59 wlb: wayland Merge request !382 opened by Julian Orth (mahkoh) protocol: explicitly disallow unpaired key events https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/382
12:21 wlb: weston Merge request !1503 opened by Marius Vlad (mvlad) clients: Remove zwp_fullscreen (fullscreen-shell) support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1503 [Clients]
14:17 wlb: weston Merge request !1504 opened by Daniel Stone (daniels) CI: Add another thread leak https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1504 [CI]
14:44 wlb: weston Merge request !1504 merged \o/ (CI: Add another thread leak https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1504)
14:44 wlb: weston/main: Daniel Stone * CI: Add another thread leak https://gitlab.freedesktop.org/wayland/weston/commit/a7b54706b580 .gitlab-ci/leak-sanitizer.supp
15:06 ammen99: Hello, I am debugging a weird crash in my compositor and I am wondering, is it possible to get any more events on an event source created with wl_event_loop_add_fd, after wl_event_source_remove is called (note that _remove() is called from inside the handler for the fd events)?
15:14 emersion: shouldn't be possible since remove() destroys the event source
15:16 ammen99: ok I wasn't sure what it does exactly (from the implementation) I thought maybe it could become inert and still some random poll could return that it is still active
15:16 ammen99: thanks
15:19 emersion: hm, right, it's not straightforward indeed, but reading in more detail i don't think this can happenb
15:19 emersion: it removes from the list and sets fd=-1
15:22 ammen99: oh yeah and then the _dispatch() checks it I see it now
19:12 xjuan: hi guys, I am trying to integrate wayland main loop with gtk main loop
19:12 xjuan: I need a way to tell if there is an idle pending so I can do the dispatch
19:13 xjuan: looking at this code https://gitlab.freedesktop.org/wayland/wayland/-/blob/main/src/event-loop.c?ref_type=heads#L773
19:13 xjuan: it seems there is no way to tell
19:13 feaneron: have you seen https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/wayland/gdkeventsource.c?ref_type=heads#L27-206 ?
19:13 xjuan: because wl_event_loop is private
19:14 xjuan: and there is no function that return the length of idle_list for example
19:15 feaneron: in particular, wl_display_prepare_read()
19:15 xjuan: but that is for the client
19:16 xjuan: I am trying to integrate the server
19:16 xjuan: but maybe its the same
19:17 feaneron: hm. this is what mutter does: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/wayland/meta-wayland.c#L118-169
19:19 xjuan: same as me but its not calling wl_event_loop_dispatch_idle()
19:20 xjuan: wl_event_loop_dispatch() does not dispatch idle sources
19:21 feaneron: if you're mixing wl_event_loop and GSource, is there anything in particular that prevents you from using GLib idle sources instead of Wayland idle sources?
19:21 xjuan: not really
19:22 xjuan: but I am using wlroots
19:22 xjuan: and they are using wayland idle sources
19:22 xjuan: I can workaround by setting a check flag in the source after I make the call to the function that queue the idle
19:23 xjuan: but that is kind of a hack
19:23 xjuan: I rather have a proper way to handle all the idles