08:38 wlb: weston Merge request !1664 opened by () libweston: fix crash when a client binds to a destroyed output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1664
14:21 MrCooper: ofourdan: re https://gitlab.freedesktop.org/xorg/xserver/-/issues/1773, Xwayland doesn't strictly need to create a separate wl_buffer for each X cursor image, does it? E.g. it could create the wl_buffers on demand and maybe keep around a pool of them for re-use
14:22 ofourdan: not sure how that would help with the issue at stake though?
14:22 wlb: weston Issue #982 closed \o/ (Is there an easy way to support specific vendor formats in weston? https://gitlab.freedesktop.org/wayland/weston/-/issues/982)
14:23 ofourdan: if the X11 client keeps creating new cursors
14:23 MrCooper: it wouldn't exhaust the SHM pool
14:24 MrCooper: and wouldn't create 10s of thousands of wl_buffers which are never attached to a surface
14:27 wlb: weston Issue #981 closed \o/ (weston keyboard not working with firefox https://gitlab.freedesktop.org/wayland/weston/-/issues/981)
14:28 MrCooper: by "create on demand" I mean create a wl_buffer, copy the cursor image contents to it, attach it to the cursor surface, then either destroy it again or keep it in a pool for future usage; not keeping around separate wl_buffers per cursor image
14:28 ofourdan: MrCooper: the problem is more with shm pixmaps though, the cursor code iteslf doesn't use shm pools, it just happens to use specifically shm pixmaps which do
14:30 MrCooper: the same issue could happen if a client leaks SHM pixmaps, sure, doesn't mean we can't do something about cursors
14:30 ofourdan: that means changing the cursor code to not use the shm pixmaps, basically.
14:31 MrCooper: I guess so
14:49 ofourdan: or maybe not…
15:20 ofourdan: there could be a very simple fix actually, using the shm pixmap the same, but just not keeping the pixmap around
15:33 ofourdan: there → https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1754
15:52 ofourdan: it works
15:52 ofourdan: more than 5000 xcursors created by teh client and counting, only one shared memory pool
17:00 bl4ckb0ne: amending protocols (bump version) require the same number of ACK as introducing a new protocol right? only the minimum discussion period time is not required