NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: xsrc/57424: Very very slow speed of X mouse pointer movement when connecting Digitizer/Pen Tablet on NetBSD 10
The following reply was made to PR xsrc/57424; it has been noted by GNATS.
From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: xsrc/57424: Very very slow speed of X mouse pointer movement when connecting Digitizer/Pen Tablet on NetBSD 10
Date: Sat, 20 May 2023 07:45:10 -0000 (UTC)
oshima-ya%yagoto-uramaya.jp@localhost writes:
>This wsmouse0 at ums0 is a USB-connected TrackPoint, normal relative mode device(a general mouse),
>wsmouse1 at ums1 and wsmouse2 at ums2 are pen tablets with the following USB connections:
>https://www.xp-pen.com/product/905.html
>⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
>⎜ ↳ /dev/wsmouse1 id=7 [slave pointer (2)]
>⎜ ↳ /dev/wsmouse2 id=8 [slave pointer (2)]
>⎜ ↳ /dev/wsmouse id=9 [slave pointer (2)]
The first decision is done by ums(4). It attaches the (relative)
trackpoint as WSMOUSE_TYPE_USB and the (absolute) touchpads as
WSMOUSE_TYPE_TPANEL (there is no "touchpad" type as types align
more to vendors than to functionality). This could be smarter, but
isn't the problem here.
wsmouse is dumb, all units are unconditionally added to wsmux0.
There should be some kind of policy on what devices to use. It
would also help to put the wsmouse types into classes that only
reflect functionality.
xorg (not xf86-input-ws) then makes the next decision. It detects
wsmouse1+2 as WSMOUSE_TYPE_TPANEL and tells xinput its a TOUCHSCREEN.
It also attaches wsmouse as a POINTER device. That's actually fine
(except for the confusing TOUCHSCREEN) but it conflicts with muxing
everything into /dev/wsmouse.
What happens if you manually remove wsmouse1+2 from the mux before
starting X ?
wsmuxctl -f /dev/wsmux0 -r wsmouse1
wsmuxctl -f /dev/wsmux0 -r wsmouse2
Home |
Main Index |
Thread Index |
Old Index