<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Trackpoint speed lock" href="https://bugs.freedesktop.org/show_bug.cgi?id=93448#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - Trackpoint speed lock" href="https://bugs.freedesktop.org/show_bug.cgi?id=93448">bug 93448</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>fwiw, if you grab evemu from git it now has the functionality to auto-resume new recordings when the device is quiet for a while, so you don't have to wrap it into a script. so, unfortunately, this recording doesn't help much, it looks like completely normal x/y movement of the trackpoint. this can be a problem: either the hw keeps sending events even when you're not touching it or libinput gets stuck somewhere. The recording here only has one gap at 12.5 seconds into it where no events happen for ~1.5 seconds. from your description this doesn't sound like that's the occurance of the bug, right? you get this bug without scrolling too, right? trackpoint motion events are a very simple code path that doesn't have any state, we just forward kernel events. so this indicates too that it's a hw issue. try if you can reproduce it with large pressure values in one direction, historically this has been how you can poke the trackpoint into doing something weird.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>