01:07 anarsoul: whot: hi, I want to try to fix crappy pinebookpro touchpad behaviour with libinput, it's pretty imprecise for small movements, how would you recommend to start?
01:09 swivel: are you sure it's fixable and not just the product of a low resolution at the hardware level?
01:11 anarsoul: swivel: well, x230 was fixable and it's pretty terrible
01:12 anarsoul: I hope it's possible for pbp as well, but yeah I'm not 100% sure
01:52 whot: anarsoul: the x230 has a custom acceleration method in libinput to make it less awful, so yeah, there's always that option but it should be a last resort
01:52 whot: anarsoul: have you looked at the actual data coming from the device and whether it's jumpy, etc.?
01:53 anarsoul: whot: how do I do that?
01:53 anarsoul: i.e. what tools to use?
01:53 whot: grab libinput from git, record a few interactions with libinput record and then run libinput analyze per-slot-delta --use-mm against the recording, that'll print you the deltas per event. any jumps should show up in there
02:13 sravn: airlied: need to apply some fixes to Documentation/../bindings/display/panel/*. robher ask to have no warnings in -rc2. Can we get drm-misc-fixes up-to-date when we hit -rc1? It is a little behind right now preventing cherry-pick of relevant fixes from drm-misc-next
02:26 airlied: sravn: yeah you have to wait for rc1, drm-fixes will go to rc1 when it rolls out
04:59 anarsoul: whot: how do I read output of libinput analyze per-slot-delta?
05:05 anarsoul: it looks like this: https://gist.github.com/anarsoul/e19d3cce87531ba93bf496ebcae63cfb
05:14 Lightsword: should I just send vc4 fixes to https://github.com/raspberrypi/linux or do I also need to send them to the mailing list in order to be included upstream?
05:14 anholt_: due to the unfortunate linux kernel process, all patches must go to the mailing list to be picked up upstream.
05:17 Lightsword: anholt_, ok, wasn't sure if someone from raspberrypi was pushing what lands there upstream
05:18 anholt_: rpi as an org is basically uninvolved upstream. they're doing some contracting that is producing patches for upstream, but they're still downstream-first.
05:19 Lightsword: ah, ok, I'll send to the mailing list as well then
05:22 whot: anarsoul: the man page explains it :)
05:22 whot: anarsoul: looks like you need --use-st, how old is this device?
05:23 anarsoul: pbp? released in 2019 :)
05:24 whot: can you pastebin the libinput record output?
05:25 anarsoul: https://gist.github.com/anarsoul/c26acd5c4d1de7720817d76b9c8da3db
05:31 whot:hands a "contratulations, you found a bug" medal to anarsoul
05:32 anarsoul: ?
05:33 whot: it's a bug in the tool, for some reason I never trigged this one on mine. fix is stacked onto https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/432
05:36 whot: anarsoul: fwiw, there's no obvious smoking gun in the analyze output. if anything, the movements are smaller than I expected but I don't know what exactly you recorded
05:37 anarsoul: whot: it feels like there's too much hysteresis on small movements
05:37 anarsoul: i.e. if I missed a button and I try to move cursor back with small movements it stays at the same place for some time
05:39 anarsoul: I wonder if it's all in firmware and it doesn't report the events at all...
05:40 whot: anarsoul: if you look at the recording, the second touch had almost no movement from the y coordinate, deltas are almost all zero
05:41 whot: anarsoul: but libinput also does deceleration for tiny movements, so there's a chance that this makes matters worse
05:42 anarsoul: is there any way to disable deceleration?
05:43 whot: if you already have a libinput build, run sudo ./builddir/libinput-debug-gui for local testing
05:43 whot: (escape closes that window btw)
05:44 whot: and in src/filter-touchpad.c, line 288 change the speed < 7.0 condition to factor = baseline, that removes the deceleration
05:44 whot: you can then play with the baseline and move it up/down a bit but that bit should immediately show whether deceleration is the issue
05:48 anarsoul: factor == baseline or factor = baseline?
05:51 Lightsword: anholt_, sent these two patches, the component one doesn't really seem vc4 specific from what I can tell though, https://patchwork.kernel.org/patch/11483961/ https://patchwork.kernel.org/patch/11483959/
05:58 whot: anarsoul: factor = baseline
05:58 anarsoul: whot: this change makes it a bit better: https://gist.github.com/ec50a74359e4015bef7b26e959f7b0d3
05:59 whot: right, so removing the deceleration helps which makes sense if the touchpad already filters to some degree
05:59 whot: best to file a bug so we can continue that there instead of irc. https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/426 may be interesting too but I havent' tested the latest version yet
06:00 anarsoul: sure, what should I attach to the bug?
06:01 anarsoul: ah, found template
06:01 anarsoul: nice
06:04 imirkin: mareko: you recently pushed some changes to nouveau_vieux, something to do with vertex fetching. which tests should i run to make sure all is still well?
06:04 imirkin: was it like client-side data vs vbo?
06:08 anarsoul: whot: https://gitlab.freedesktop.org/libinput/libinput/-/issues/468
06:09 anarsoul: I guess I'll use libinput with this one liner meanwhile :)
06:22 whot: thx. it'll take a while before I get to it, depends on 426 I guess too
07:05 sravn: airlied: fino, will wait for -rc1 and ping if -fixes is not updated a few day lates
09:04 hakzsam: anholt_: yes, got some reports like and they looked strange to me because no gitlab-ci.yml changes in those MRs. I don't know what happened
13:18 MrCooper: anholt_ hakzsam: AFAICT it's because some of the test jobs are 'when: manual' on forked project branches, but other jobs they depend may be 'when: never', in which case the pipeline breaks
13:21 MrCooper: adding 'changes: *all_paths' to the 'when: manual' rule of .test-manual might do the trick
13:35 MrCooper: anholt_ hakzsam: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4522
20:19 dj-death: anybody ever tried to use apitrace on Xorg?
20:39 dj-death: ah well... I'm able to trace but no texture data is actually there
20:40 dj-death: it's all dmabuf imported
21:43 mareko: imirkin: removal of NullBufferObj
21:45 imirkin: mareko: yeah, but ... what do i need to test in terms of like piglits and whatnot?
21:45 imirkin: or is there not a specific thing?
21:46 mareko: imirkin: not a specific thing
21:48 mareko: is Kayden doing? I've heard he was on vacation. Has he been able to get back home?
21:48 mareko: *how is
21:49 imirkin: mareko: ok. i'll poke around. unfortunately i have a Riva TNT2 atm, so no T&L :)
21:58 dj-death: mareko: still on holidays for a week or so