02:44 <LoneStarr> I have a really buggy touchpad, which keeps popping me up or down when two finger scrolling. Am willing to gather detailed debug info and submit to others if anyone can steer me towards a solution that might include softening the response rates. So far I have not figured out how to change acceleration curves or anything.

02:44 <whot> "popping me up"? I think I might need a rephrasing of that bit :)

02:45 <LoneStarr> More often scrolling down than up, so it's accurate

02:46 <whot> if you get a buggy sequence with libinput record and attach that to a issue we can look at it. there's a libinput analyze per-slot-delta tool that will show you what the individual touch points do, that may help too

02:47 <whot> because that's the first tool I'll run when seeing the recording. There's a chance the touchpad is a semi-mt touchpad but not labelled as such which can cause that sawtooth movement

02:47 <LoneStarr> OK, I've cloned the libinput repo already to this host, and have explored some of the info gathering tools, but I couldn't make sense of what to do in one or two captures.

02:48 <LoneStarr> Are there specific movements that help with the captures? Like if I record just one motion then exit, or snip timestamps to frame the events of interest?

02:49 <whot> just record one motion and hope it's representative enough. you can use libinput replay to replay the recording to make sure it reproduces the bug

02:50 <LoneStarr> To describe the behavior in a nutshell, it seems ok, when sufficient pressure is applied, but as the fingers are leaving the surface or if fine changes are being requested, it seems to send a quick acceleration in the opposite direction, which is sometimes picked up as a desire to continue past the release

02:51 <whot> have you tried tweaking the pressure thresholds?

02:52 <LoneStarr> Thank you. I will get back into it, soon and post to the Issues list. Also, if you or others send me in a certain direction I'll mess around with code any way that can help out. I was thinking I might need to depend on a local modification in the end. No, I didn't observe where I could make changes other than tools like those provided by desktop environment settings.

02:52 <whot> https://wayland.freedesktop.org/libinput/doc/latest/touchpad-pressure-debugging.html

03:08 <LoneStarr> This is really helpful. Thank you for responding! Is there any way for me to observe the current settings for touch-thresholds before I make changes??

03:09 <whot> not in your session, you can run those tools and they'll display what the touch is internpreted at. You can run libinput debug-gui as a test gui but that may not be sufficient

03:09 <whot> but should be good enough to get an idea of whether it works and then you can restart the session

04:09 <LoneStarr> Hmm, by session, do you mean the graphical login? I have not written the changes to local quirks yet, but if I remove those local quirks I can still take a pristine record capture?

04:10 <whot> libinput record doesn't care about quirks, it records kernel events so it sits below quirks

04:10 <whot> but yes, session is the graphical login, restarting that (log out/in) gives you a new libinput context

04:10 <LoneStarr> I'm setting the local quirks now, guessing I can remove the file to reset to defaults. measure touchpad-pressure seems to have Palm and Thumb transposed, based on the P>O>M>N

04:12 <whot> could be, PR appreciated :)

04:12 <whot> remove/rename the file gives you back the defaults, yes

05:17 <LoneStarr> Well, the good news is my quirks have been picked up (should be effective) and are valid. But sadly the bounce-back behavior is kind of the bad news.

05:18 <LoneStarr> I've also noticed that the touchpad picks up a signal from my fingers several millimeters hovering over the surface of the touchpad. I'll work on making a recording and a ticket.

05:29 <whot> LoneStarr: we do have support for hovering touches on touchpads (some touchpads from years ago gave us grief) so you may be lucky if we can modify that easily

05:30 <whot> if you grep for hover you should see the various bits but i can't really remember what exactly we did

05:55 <LoneStarr> Sorry Peter, I didn't mean to consume so much of your time and communications. My device is similar to the one on issue #1059, so I'm reviewing what was the result of that issue. My quirks list also only included that one line.

06:21 <whot> LoneStarr: probably best to file a new issue because that one is a bit of a mess

06:22 <LoneStarr> Thank you. I'll probably mention it again in the ticket, but please push any tasks off onto me that you can think of, I would like to help you out by removing the workload, and ultimately we can help other users out, who have no idea how to reach out.

06:23 <whot> esp because (iirc) it was a bit hard to figure out what it was *supposed* to do based on the recordings because the data in the recordings is all have to analyse, so we need to match this with the user's intent too

06:23 <whot> is it the same thinkpad model?

07:40 <wlb> wayland/main: Pekka Paalanen * doc: add a section on color management https://gitlab.freedesktop.org/wayland/wayland/commit/ba9f9a446f74 doc/publican/sources/ Color.xml Wayland.xml meson.build

07:40 <wlb> wayland Merge request !479 merged \o/ (doc: add a section on color management https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/479)

07:55 <pq> How do we update https://wayland.freedesktop.org/docs/html/ again?

07:58 <pq> wayland-web CI seems to have it...

08:01 <pq> ok, looks like it's automatic when a new non-RC release of libwayland is added to wayland-web

08:06 <pq> emersion, in wayland.git, I see the 1.23.92 tag on main branch without a commit to bump the version. Should the tag have been on the 1.24 branch?

08:07 <emersion> ew, maybe I messed up, will look into it later today

08:08 <pq> thanks

08:22 <jadahl> zzag: just curious, is xx_pip_v1 unconditionally exposed to users by default in kwin now?

08:24 <davidre> jadahl: It's hidden behind KWIN_WAYLAND_SUPPORT_XX_PIP_V1 environment variable

08:26 <jadahl> I see

08:28 <jadahl> would be good to know what various compositors "opinions" are about xdg_pip, related to the biggest hurdle of output-only vs output/input and mapping heuristics about tying it to input events ala grabbing popups etc

08:53 <LoneStarr> Sorry I was focusing, then distracted, and composing ticket details. This is an HP 15-f272wm. There was some mention in the tools while preparing attachments about the local hwdb tests, but those are still not used any longer, I believe

09:19 <whot> the hwdb is somewhat in use but only for axis overrides and the fuzz handling. axis overrides should go into systemd, fuzz handling too (it's an axis override) but the way the fuzz works is a bit awkward so we have to do some of it

10:15 <emersion> jadahl: I agree with zzag fwiw

10:56 <zzag> Perhaps we could have a session about pip at XDC? It's in September, but it's not that far away

11:37 <emersion> sounds like a good idea if we don't agree by then

14:48 <wlb> weston Merge request !1777 opened by Pekka Paalanen (pq) Improvements to color transformation debug prints https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1777 [color-lcms plugin], [Colour management]