Hi Jonathan,
Thanks for testing. That seems to confirm that /dev/wsmouse is where the
jumps are coming from.
The loss of the three buttons also makes some sense. They may be part of
the pms0/TrackPoint interface rather than the imt0 touchpad interface. Your
dmesg shows:
wsmouse0 at imt0
wsmouse1 at ims0
wsmouse2 at pms0
Perhaps the next test is to ignore the multiplexed /dev/wsmouse, but open
/dev/wsmouse2 directly:
Section "InputClass"
Identifier "ignore wsmouse mux"
MatchDevicePath "/dev/wsmouse"
Option "Ignore" "true"
EndSection
Section "InputDevice"
Identifier "TrackPoint and buttons"
Driver "ws"
Option "Device" "/dev/wsmouse2"
Option "AutoServerLayout" "true"
EndSection
This would leave /dev/wsmouse0 handling the touchpad through synaptics,
while /dev/wsmouse2 handles the TrackPoint and its buttons without going
through the multiplexor.
After restarting X, does `xinput list` show both /dev/wsmouse0 and the
separately configured wsmouse2, but not /dev/wsmouse?
If so, it would be interesting to see whether the touchpad, buttons and
TrackPoint then work without the jumps.
I haven't tested this particular setup, so please keep the previous
xorg.conf handy in case X does not add wsmouse2 this way.
Regards,
Kihaguru
On Tue, 4 Aug 2026, 08:41 Jonathan Thornburg, <[email protected]>
wrote:
> Hi Kihaguru,
>
> Thanks for your analysis!
>
> On Sun, Aug 02, 2026 at 11:07:38PM +0300, Kihaguru Gathura wrote:
> > Hi Jonathan,
> >
> > The interesting part of the log may be that X is opening more than one
> > interface for the pointing devices:
> >
> > /dev/wsmouse0 - imt0 touchpad, using synaptics
> > /dev/wsmouse1 - ims0 report, which fails to enter native mode
> > /dev/wsmouse - the wscons multiplexor
> >
> > So the touchpad may be reaching X directly through wsmouse0 and again
> > through the multiplexor. The multiplexor may also carry events from the
> > TrackPoint at pms0. The jump when you first move the TrackPoint makes
> that
> > path especially suspicious.
>
> Aha! That does seem "curious"....
>
> > As a quick test, run: xinput list , then disable the entry named
> > /dev/wsmouse, for example: xinput disable 8
> >
> > Use the actual id from `xinput list`, since it may change. This should
> > leave /dev/wsmouse0 handling the touchpad.
>
> Here's the output of 'xinput list' before disabling anything:
> % xinput list
> + Virtual core pointer id=2 [master pointer
> (3)]
> | + Virtual core XTEST pointer id=4 [slave pointer
> (2)]
> | + /dev/wsmouse0 id=7 [slave pointer
> (2)]
> | + /dev/wsmouse id=8 [slave pointer
> (2)]
> + Virtual core keyboard id=3 [master keyboard
> (2)]
> + Virtual core XTEST keyboard id=5 [slave keyboard
> (3)]
> + /dev/wskbd id=6 [slave keyboard
> (3)]
> %
>
> After 'xinput disable 8' three things happened:
> * [good] the cursor no longer jumped
> * [neutral] the trackpoint ("nipple") becomes a no-op
> * [bad] the touchpad's 3 mechanical buttons also become no-ops (tapping
> the touchpad seems to work, but I'm very used to using the touchpad's
> mechanical buttons)
>
> After returning to the initial state with 'xinput enable 8',
> I tried 'xinput disable 7' (disabling /dev/wsmouse0). This had
> different results:
> * [very bad] the cursor now jumps with *every* touchpad movement
> * [neutral] the trackpoint ("nipple") works, but the cursor jumps
> with every trackpoint movement, too
> * [ok] the touchpad buttons work ok
>
> ciao,
> --
> -- "Jonathan Thornburg [remove -color to reply]" <
> [email protected]>
> he/him; on the west coast of Canada; https://www.bkis-orchard.net/
> "He wakes me up every morning meowing to death because he wants to go
> out, and then when I open the door he stays put, undecided, and then
> glares at me when I put him out"
> -- Nathalie Loiseau (French minister for European Affairs,
> explaining why she named her cat "Brexit")
>
