01:12 wlb: wayland Issue #386 opened by Dee H.Y (dongfengweixiao) The transmission-qt context menu content cannot be displayed https://gitlab.freedesktop.org/wayland/wayland/-/issues/386
05:34 wlb: wayland Issue #386 closed \o/ (The transmission-qt context menu content cannot be displayed https://gitlab.freedesktop.org/wayland/wayland/-/issues/386)
07:35 pq: mort_, is the touch scroll speed problem the same on more than one DE or compositor? If yes, you could open a libinput bug asking about it; if no, you could open a compositor bug asking about it.
07:58 mort_: pq: sway seems to be around the same by default at least
07:59 pq: interesting that it happens on multiple compositors *and* multiple hardware
07:59 mort_: yeah
07:59 pq: and it's not an X11 app where you hit it either? nothing specific to any app?
08:00 mort_: no, seems about the same in all software (at least GTK software, I haven't really tested Qt much tbh)
08:02 mort_: the hardware I've tested the most is two Dell laptops (an xps 13 from 2015 and an xps 15 from 2018) and a macbook pro running asahi linux
08:02 pq: is there anything common between all the machines you've tried, other than libinput being part of the stack? no copied system or user settings between them?
08:03 mort_: nope, happens with fresh installs
08:03 mort_: and I wouldn't expect Dell and Apple to share very similar touchpad configs on the libinput side
08:04 pq: if it was a libinput bug, it should affect many users, get reported, and fixed, but this is baffling.
08:05 mort_: I agree
08:05 pq: whot, any ideas? ^
08:06 mort_: especially that it's apparently seen as such a non-problem that the biggest DE doesn't even have a scroll speed setting is weird
08:06 mjt: maybe it's just about the missing DPI settings for this particular device?
08:07 pq: it guess the speed was supposed to be on par with cursor movement, and for you it isn't?
08:07 mort_: it seems very far away from the speed of cursor movements
08:07 mjt: ah.. nope it is not :)
08:07 mort_: I don't have time today, but tomorrow or something I can make some proper measurements
08:09 pq: a confusion in scroll units could do that, but where should that bug be to have the scope of impact like this
08:09 ofourdan: the difference may be possibly because of the hires scroll events, you may want to capture the WAYLAND_DEBUG logs and we what gets send to the app.
08:10 ofourdan: *and see
08:10 ofourdan: *gets sent
08:10 ofourdan: (grr, friday…)
08:12 mort_: I wonder how many people are actually using a laptop with a high res scrolling style trackpad, and how many just use old school scroll wheel emulation trackpads or mice
08:13 mort_: I mean if you google something like "wayland scrolling too fast" you see a whole load of results
08:25 wlb: weston Merge request !1264 opened by Philipp Zabel (pH5) pixman-renderer: Add to_pixman_renderbuffer helper https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1264
08:55 wlb: weston Merge request !1265 opened by Philipp Zabel (pH5) backend-wayland: fix memory leak in wayland_shm_buffer_attach https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1265
09:02 kennylevinsen: mort_: how are you comparing cursor movement with scroll speed? Acceleration difference between the two will give noisy results...
09:03 mort_: I haven't done any measurements, I'm currently only going by feel
09:04 kennylevinsen: in my case (firefox, wlroots, xps13), scrolling the height of the touchpad gives ~3 screen heights irrespective of speed. Moving cursor very slow gives ~0.5x height, but moving it fast gives at least ~2 screen heights
09:04 kennylevinsen: (no idea how much more than 2 screen heights, as the cursor bumps into the edge)
09:06 mort_: how about scrolling slowly vs scrolling quickly?
09:07 kennylevinsen: no apparent effect on distance in this test
09:09 kennylevinsen: so the subjective feeling is that at high speed they match, but the cursor is slowed down a lot by its acceleration profile at low speeds. as one is likely to move slow during comparison for repeatability, that might distort the result a bit...
09:11 kennylevinsen: it's been quite a few years since I daily drove macOS, so I don't remember their touchpad behavior (apart from it feeling more natural to me to use than other platforms' default touchpad behavior)
09:12 mort_: am on macOS right now, it seems like scrolling fast with two fingers moves about twice as far as moving slow
09:13 wlb: weston/main: Liu, Kai1 * xwm: WM_TRANSIENT_FOR should not point to override-redirect window https://gitlab.freedesktop.org/wayland/weston/commit/b468687dd266 xwayland/window-manager.c
09:13 wlb: weston Merge request !1256 merged \o/ (xwm: WM_TRANSIENT_FOR should not point to override-redirect window https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1256)
09:16 wlb: weston Merge request !1266 opened by Philipp Zabel (pH5) backend-vnc: render bypass support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1266
09:17 wlb: weston/main: Philipp Zabel * pixman-renderer: Add to_pixman_renderbuffer helper https://gitlab.freedesktop.org/wayland/weston/commit/0d4c523c4c1e libweston/pixman-renderer.c
09:17 wlb: weston Merge request !1264 merged \o/ (pixman-renderer: Add to_pixman_renderbuffer helper https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1264)
09:20 wlb: weston/main: Philipp Zabel * backend-wayland: fix memory leak in wayland_shm_buffer_attach https://gitlab.freedesktop.org/wayland/weston/commit/2c7dceced7da libweston/backend-wayland/wayland.c
09:21 wlb: weston Merge request !1265 merged \o/ (backend-wayland: fix memory leak in wayland_shm_buffer_attach https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1265)
09:25 wlb: weston/main: Daniel Stone * 5 commits https://gitlab.freedesktop.org/wayland/weston/compare/2c7dceced7da57411750706f7baa87f6f281e0ea...499e617a627a4e7f6e8fba54e55df5e740419a59
09:25 wlb: weston Merge request !1106 merged \o/ (gl-renderer: add FBO output support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1106)
09:30 wlb: weston Merge request !1267 opened by Philipp Zabel (pH5) renderer-gl: drop unused fields from struct gl_fbo_texture https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1267
09:32 wlb: weston Merge request !657 closed (Cleanup memory allocated to child processes at the time of exit)
09:47 wlb: weston/main: Philipp Zabel * gl-renderer: remove pbuffer dummy surface https://gitlab.freedesktop.org/wayland/weston/commit/2122be5a13b0 libweston/renderer-gl/ gl-renderer-internal.h gl-renderer.c
09:47 wlb: weston Merge request !1259 merged \o/ (gl-renderer: remove pbuffer dummy surface https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1259)
09:50 wlb: weston/main: Philipp Zabel * renderer-gl: drop unused fields from struct gl_fbo_texture https://gitlab.freedesktop.org/wayland/weston/commit/7bc5cf9ca6ac libweston/renderer-gl/gl-renderer.c
09:51 wlb: weston Merge request !1267 merged \o/ (renderer-gl: drop unused fields from struct gl_fbo_texture https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1267)
13:23 wlb: wayland Issue #387 opened by Simon Ser (emersion) Clarify whether wl_buffer destruction after wl_surface.attach is allowed https://gitlab.freedesktop.org/wayland/wayland/-/issues/387 [Protocol]
13:41 daniels: pq: assuming you haven't already left for the weekend - do you remember why you made subsurface views only materialise at repaint time rather than immediately on commit?
13:43 pq: daniels, two reasons I guess: to help the shell ignore them when it re-stacks top-level views, and just in case the shell wants to have multiple views for a top-level surface.
13:44 pq: commits per se do not materialize views at all, it is always the role "driver" that decides when, how many, and what kind of views get created or removed
13:45 pq: cursor surface could have sub-surfaces too, etc.
13:51 pq: daniels, also I think it was gfxstrand who split views out of surfaces, which was after sub-surfaces already existed :-)
13:51 pq: oh, that was almost 10 years ago
13:51 pq: like 9.5
13:54 pq: so, the idea is that role drivers can manage their views obliviously, and if the surface happens to have sub-surfaces, then the sub-view magically materialize and disappear according to the sub-surface rules on all main views.
13:56 daniels: yeah, gotcha
13:56 daniels: do you think that's still a sensible design?
13:56 daniels: (this is a yak-shave from moving damage down to paint nodes)
13:57 pq: I guess weston_view is doing too much, and would need splitting into "main views" that role drivers manage and stack, and into... hmm... paint-nodes? that then magically appear as needed and in the correct stacking
13:58 pq: implying that sub-surfaces would not have views... no, maybe there needs to be a "scenegraph view" that is not per-output thing like paint-node
13:59 pq: daniels, I'm not sure it ever was a sensible design :-)
13:59 pq: it just worked enough
14:01 pq: maybe there should also be a weston_window that is a weston_surface + sub-surfaces, so that we don't have two tiers of weston_surface: normal and sub
14:02 pq: but that's a bit awkward, since only applying a role would make that difference, so might as well be the role-specific object
14:02 wlb: weston Merge request !1268 opened by Michael Tretter (m.tretter) Draft: backend-pipewire: add GL renderer support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1268
14:04 daniels: pq: I think we still need to have subsurface views, but indeed like you say need to have a hard split between frontend-managed views and magic backend-materialised views
14:10 pq: I recommend starting from a clean sheet and thinking what would be ideal, without worrying how to get there.
14:15 daniels: you know full well that's how I work :D
15:39 wlb: weston/main: Philipp Zabel * gl-renderer: split gl_renderer_do_read_pixels out of gl_renderer_do_capture https://gitlab.freedesktop.org/wayland/weston/commit/4a271bdaaef9 libweston/renderer-gl/gl-renderer.c
15:39 wlb: weston/main: Philipp Zabel * gl-renderer: support automatically downloading FBO renderbuffers https://gitlab.freedesktop.org/wayland/weston/commit/b1606a9f2cff libweston/ backend-headless/headless.c renderer-gl/gl-renderer.c renderer-gl/gl-renderer.h
15:39 wlb: weston Merge request !1263 merged \o/ (gl-renderer: optionally read pixels into software buffer in repaint_output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1263)
15:42 wlb: weston Merge request !1107 merged \o/ (backend-vnc: GL renderer support https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1107)
15:42 wlb: weston/main: Philipp Zabel * backend-vnc: GL renderer support https://gitlab.freedesktop.org/wayland/weston/commit/0d64d0ac5c33 libweston/backend-vnc/vnc.c