00:52 wlb: weston Merge request !1261 opened by Sergio Gómez (SergioGDR) Implement proper z-order for xdg surfaces in the kiosk shell https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1261
07:49 pq: daniels, a bit harsh to call me an enthusiast when pbuffers have always been just a trick to avoid complicating internal Weston APIs or to cater for proprietary drivers that cannot do surfaceless etc. EGL extensions. :-)
07:50 daniels: pq: sorry!
07:51 pq: daniels, I should asking *you* if there are any platforms left that need pbuffers, as I wouldn't know.
07:51 daniels: afaik no, happily!
07:51 pq: I'm not at all attached to pbuffers, if stuff works otherwise. :-)
07:52 daniels: \o/
07:53 pq: just make sure to get the coordinate systems right
07:53 pq: and none of that "I flipped it because I saw it upside-down" nonsense
07:55 daniels: /o\
07:55 pq: daniels, is the plan to get completely rid of EGLSurface usage on all platforms?
07:56 daniels: pq: that could happen as this makes it much easier but it wasn’t the plan - this is motivated by GL support for RDP/VNC
07:57 pq: even for X11 backend?
07:58 daniels: X11/Wayland/DRM are not touched in these MRs, but it would make it much easier to
07:58 pq: would be nice to have just a single renderer path
07:58 pq: no, I'm talking about future plans
07:58 daniels: ack
07:59 daniels: it would mean having those backends implement zwp_linux_dmabuf_v1/DRI3 which is annoying but doable
08:00 pq: so it actually is feasible for DRM-backend nowadays to stop using EGL GBM platform from the driver support perspective?
08:00 pq: even on embedded?
08:01 daniels: absolutely, I believe so
08:01 pq: cool
08:01 pq: I have nothing against such plans.
08:03 pq: but yeah, getting rid of the EGLSurface on Wayland and X11 may not be worth the cost, compared to having to maintain two paths (FBO and EGLSurface) in GL-renderer.
08:04 jadahl: I was considering getting rid of EGLSurface in mutter, but those plans were put on hold because some driver optimizations depend on EGLSurface being used
08:05 pq: oh?
08:10 emersion: pq, https://github.com/KhronosGroup/OpenGL-Registry/issues/547
08:10 emersion: jadahl: if you have evidence that these optimisations matter, please comment on that issue
08:11 pq: daniels, so I read through the commit messages of 1106, even glanced at the code and left couple comments, but no objections to the idea.
08:18 pq: ooh, partial update
08:20 emersion: fwiw we've been using FBOs exclusively in wlroots for years
08:20 jadahl: emersion: "I checked the impact of this with the lima driver using the hardware performance counters for number of memory reads and writes done by the GPU.
08:20 daniels: emersion: amusingly, the people who passionately and vehemently insisted it was necessary, and that buffer_age+scissor+no-blend could never replicate the effect, which is why they blocked KHR for that extension and wrote buffer_age, are now being contradicted by their colleagues who shrug and claim it’s fine :)
08:20 jadahl: There is a drop in those numbers, sometimes significant"
08:20 jadahl: from https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2023
08:21 daniels: interesting
08:21 daniels: great to see everything is still completely confused
08:22 jadahl: utter confusion is why AI can't replace us
08:22 pq: emersion, does wlroots run fine on separate and independent KMS and GPU devices on SoCs? daniels, are SoCs with no common formats between GPU rendering and KMS still a use case?
08:23 daniels: pq: I noted the FBO format thing in one of the sub-MRs btw - hopefully it could help clean up some of the internal-FBO code at some point
08:24 daniels: afaik it’s only i.MX6 left which does that, and you can I believe still render to linear gbm_bo (with an internal resolve)
08:24 emersion: lol
08:24 emersion: thanks jadahl
08:25 emersion: pq, yes, it runs fine, but had to carefully design the architecture for that
08:25 emersion: we don't support setups where there's no common format between render and display devices
08:27 pq: daniels, emersion, ok, thanks. Sounds good enough.
09:02 wlb: weston/main: Marius Vlad * libweston/backend-headless: Remove cleanup_after_cairo() https://gitlab.freedesktop.org/wayland/weston/commit/44d185138f69 libweston/backend-headless/headless.c
09:02 wlb: weston/main: Marius Vlad * gitlab-ci/leak-sanitizer.supp: Suppress entire libfontconfig https://gitlab.freedesktop.org/wayland/weston/commit/55a6216a5dc2 .gitlab-ci/leak-sanitizer.supp
09:02 wlb: weston/main: Marius Vlad * virtme-scripts: Add LSAN_OPTION https://gitlab.freedesktop.org/wayland/weston/commit/f043ad364725 .gitlab-ci/virtme-scripts/per-test-asan.sh
09:02 wlb: weston Merge request !1251 merged \o/ (libweston/backend-headless: Remove cleanup_after_cairo() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1251)
10:29 MrCooper: emersion jadahl: AFAICT, without that MR mutter doesn't use glScissor for each rect though (possibly a single glScissor for the bounding box, not sure)
10:31 pq: Weston is not using Scissor at all...
10:32 emersion: wlroots was using scissors, but not anymore on GL (and soon will drop from Vulkan too)
10:32 pq: what made wlroots drop it?
10:33 emersion: we found that perf was better without scissors
10:33 pq: ha
10:33 pq: even on Vulkan?
10:33 emersion: haven't tried yet
10:34 pq: I'd totally believe that OpenGL state handling could have a perceivable overhead.
10:35 daniels: emersion: ... without?
10:35 daniels: on which hardware?
10:36 pq: I suppose Scissor cannot be arbitrarily complex, while lots of primitives could be packed into a single draw call...
10:36 emersion: all hw really
10:36 emersion: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4135#note_1922081
10:36 emersion: checked both CPU and GPU usage
10:37 daniels: mm, I guess the difference is that glScissor forces the implementation to clip and discard anything outside the bounds, whereas partial_update is a promise by the application that it won't be doing anything outside the bounds
10:39 emersion: it was surprising to me i must admit
10:43 pq: In Weston I would kinda like to batch all primitives (either opaque or blended) into a single draw call, but that means the geometry can be arbitrarily complex.
10:44 pq: Right now Weston is doing one draw call per damage rect.
10:49 pq: batch per wl_surface
11:03 daniels: *weston_view?
11:03 daniels: **weston_paint_node
11:04 pq: per paint-node, true
11:05 wlb: weston/main: Philipp Zabel * gl-renderer: split buffer age query out of output_get_damage https://gitlab.freedesktop.org/wayland/weston/commit/38181e1748aa libweston/renderer-gl/gl-renderer.c
11:05 wlb: weston/main: Philipp Zabel * gl-renderer: track damage on dummy renderbuffers https://gitlab.freedesktop.org/wayland/weston/commit/fb91919fa20a libweston/renderer-gl/gl-renderer.c
11:05 wlb: weston/main: Philipp Zabel * gl-renderer: remove old damage tracking https://gitlab.freedesktop.org/wayland/weston/commit/3010d1f0707f libweston/renderer-gl/gl-renderer.c
11:05 wlb: weston Merge request !1260 merged \o/ (gl-renderer: use dummy renderbuffer structures for damage tracking https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1260)
11:05 pq: cannot batch multiple paint-nodes because they might need different shaders
11:48 ofourdan: emersion, pq, any objection to me releasing a new version of wayland-utils now?
11:51 emersion: ofourdan: none
11:54 ofourdan: thanks!
11:57 wlb: weston Merge request !1262 opened by Philipp Zabel (pH5) gl-renderer: add GL_RGB10_A2 support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1262
12:21 pq: go for it
12:21 ofourdan: cheers! let's go then!
12:27 wlb: weston Merge request !1262 closed (gl-renderer: add GL_RGB10_A2 support)
12:28 ofourdan: humm
12:28 ofourdan: "release failed after 1.09s error=POST https://gitlab.freedesktop.org/api/v4/projects/wayland/wayland-utils/releases/1.2.0/assets/links: 400 {error: link_type does not have a valid value}"
12:28 ofourdan: any idea what that means ^^^
12:28 ofourdan: ?
12:29 ofourdan: maybe my version of glab is too old?
12:37 ofourdan: yeah, that was it :)
12:44 emersion: yep, was a glab bug
13:01 wlb: wayland.freedesktop.org/main: Olivier Fourdan * releases: add wayland-utils 1.2.0 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/2a5ec8f50d92 releases.html
13:22 wlb: weston Merge request !1263 opened by Philipp Zabel (pH5) gl-renderer: add framebuffer object name to gl_renderbuffer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1263
13:32 emersion: jadahl: are you fine with https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/312 ?
13:36 jadahl: emersion: yes, seems fine. the question was whether to include opaque structs, but seems less important I guess
15:56 wlb: wayland-protocols Issue #143 opened by Gregory Merchan (gregory.merchan) xdg-shell: support background window actions https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/143
17:28 wlb: wayland Issue #385 opened by Simon Ser (emersion) doc/doxygen: HTML_TIMESTAMP is obsolete https://gitlab.freedesktop.org/wayland/wayland/-/issues/385 [Documentation]
20:09 mort_: ever since the world moved to libinput I've felt like touchpad scrolling was way too sensitive... and I feel like I might've found a clue? Scroll speed feels perfectly reasonable when I put two fingers on the trackpad but only move one of them. So maybe the scroll delta which ends up being used is the sum of the two movements and not their average?
20:54 mort_: I don't know, that might not be the explanation. But scrolling is for sure consistently at least twice as fast as it "should" be across all hardware I've tested (which includes a few different brands).
20:56 ManMower: doesn't your compositor have some sort of scroll speed setting you could just adjust to 1/2 of what it is now?
20:56 ManMower: I'm surprised moving a single finger of the two doesn't trigger as a pinch gesture. but I suspect the reason that moves 1/2 speed is just that the math ends up reporting the distance moved as the center between the fingers, giving you half of moving both
20:57 ManMower: I doubt this is really some kind of bug in libinput though - it just wasn't written with "maintain the exact behaviour of legacy systems" in mind, and just defaults to being faster
20:57 ManMower: but take all of that with a pinch of salt. I'm not really an input guy. :)
21:02 mort_: GNOME doesn't have a scroll speed setting
21:02 mort_: moving only one finger does trigger a pinch gesture, but if you start moving both fingers and then stop one it keeps the scroll gesture
21:03 mort_: there is *definitely* a bug here somewhere, since the scroll speed is truly ridiculously unbelievably fast across all hardware I have tested
21:04 mort_: as in "scroll tens of pages in one swipe" fast
21:05 mort_: maybe that's an exaggeration but you get the point. The way I've heard it described is that scroll distance should be about equivalent to cursor movement distance for the same sized movement, and it's very far from that