ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
abeltramo583 has joined #wayland
abeltramo58 has quit [Read error: Connection reset by peer]
abeltramo583 is now known as abeltramo58
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
kasper93 has joined #wayland
kasper93_ has quit [Ping timeout: 480 seconds]
kasper93 has quit [Remote host closed the connection]
iomari891 has quit [Read error: Connection reset by peer]
sima has joined #wayland
Lyude has quit [Quit: Bouncer restarting]
Lyude has joined #wayland
tzimmermann has joined #wayland
iomari891 has joined #wayland
<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.
rasterman has joined #wayland
<mort_>
pq: sway seems to be around the same by default at least
<pq>
interesting that it happens on multiple compositors *and* multiple hardware
<mort_>
yeah
<pq>
and it's not an X11 app where you hit it either? nothing specific to any app?
<mort_>
no, seems about the same in all software (at least GTK software, I haven't really tested Qt much tbh)
<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
<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?
<mort_>
nope, happens with fresh installs
<mort_>
and I wouldn't expect Dell and Apple to share very similar touchpad configs on the libinput side
<pq>
if it was a libinput bug, it should affect many users, get reported, and fixed, but this is baffling.
<mort_>
I agree
<pq>
whot, any ideas? ^
<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
<mjt>
maybe it's just about the missing DPI settings for this particular device?
<pq>
it guess the speed was supposed to be on par with cursor movement, and for you it isn't?
<mort_>
it seems very far away from the speed of cursor movements
kasper93 has joined #wayland
<mjt>
ah.. nope it is not :)
<mort_>
I don't have time today, but tomorrow or something I can make some proper measurements
<pq>
a confusion in scroll units could do that, but where should that bug be to have the scope of impact like this
<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.
<ofourdan>
*and see
<ofourdan>
*gets sent
<ofourdan>
(grr, friday…)
<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
<mort_>
I mean if you google something like "wayland scrolling too fast" you see a whole load of results
<kennylevinsen>
mort_: how are you comparing cursor movement with scroll speed? Acceleration difference between the two will give noisy results...
<mort_>
I haven't done any measurements, I'm currently only going by feel
<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
<kennylevinsen>
(no idea how much more than 2 screen heights, as the cursor bumps into the edge)
<mort_>
how about scrolling slowly vs scrolling quickly?
<kennylevinsen>
no apparent effect on distance in this test
junaid has joined #wayland
<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...
<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)
<mort_>
am on macOS right now, it seems like scrolling fast with two fingers moves about twice as far as moving slow
<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?
<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.
<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
<pq>
cursor surface could have sub-surfaces too, etc.
rv1sr has quit []
<pq>
daniels, also I think it was gfxstrand who split views out of surfaces, which was after sub-surfaces already existed :-)
<pq>
oh, that was almost 10 years ago
<pq>
like 9.5
<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.
<daniels>
yeah, gotcha
<daniels>
do you think that's still a sensible design?
<daniels>
(this is a yak-shave from moving damage down to paint nodes)
<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
<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
<pq>
daniels, I'm not sure it ever was a sensible design :-)
<pq>
it just worked enough
<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
<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
<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
<pq>
I recommend starting from a clean sheet and thinking what would be ideal, without worrying how to get there.