Ping? No further thoughts on this, no tests? Do I have to conclude that
most people are happy with wsmouse as it is?
I'm aware that the diff isn't small, but anything smaller would make
some of the remaining parts void and possibly blur the concept. The core
of the approach is actually quite simple: wsmouse_input() will be
replaced by a set of functions for reporting state, and by
wsmouse_input_sync(), which generates the wscons events (please note
that it doesn't produce MT events yet; there are no userland drivers
that could use them). Running mice, and tablets and touchpads that can
only track a single contact wouldn't need much more. MT support needs
some bits of configuration: the number of touches that might be tracked
simultaneously, and the information whether a buffer for "MT tracking"
is required.
For use with the synaptics driver, MT input from touchpads must be
converted into a single-touch representation, and this conversion is
based on a mechanism that selects a "pointer-controlling" slot. The
implementation generalizes the method currently applied by the
Elantech-v4 packet handler in pms.
Single-touch representations are also the base for handling
"compat-mode" of touchpads in wsmouse. Currently, each hardware driver
tracks absolute coordinates in its device data, and has a compat-mode
branch in its packet handler that computes relative coordinates, applies
a more or less arbitrary scaling to them, and calls wsmouse_input() with
the "DELTA" flags. This is not only ugly, it would be even more ugly for
touchpad drivers that use the new MT functions: It would still require a
driver-internal representation of the input, a driver-internal selection
of the pointer-controlling touch, etc. That's obviously nonsense, compat
mode should be handled by wsmouse. However, it requires some
configuration.
There is a second point concerning compat mode that I would like to
change: it could be made useful. Because of the arbitrary scaling and
the unpredictable pointer movement, I cannot use it with wsmoused at the
console. Do touchpads exist where it works? Recently Thierry Deval
posted a diff here which proved that we could easily do something about
that, but that is a different story. In my diff, wsmouseinput hooks its
"touchpad extension" (wstpad) into the compat-mode conversion function,
which works well with ws for all touchpads that are available to me.
The internal configuration of wstpad may cause headaches, it seems to be
easy to make a mess out if it. This is one of the reasons why there are
no ioctl mechanisms yet for a configuration from userland.
Up to now, I had less headaches with the input-processing parts of
wstpad, and I don't believe that a decent driver necessarily looks like
the synaptics driver, or the touchpad module of libinput. Its tapping
handler, for example, seems to be built on a somewhat unlucky
abstraction (I mean the "state machine", where states mirror input
states and sequences of input states; in wstpad, the "states" of the
handler correspond the kind of decision that is to be taken next). Of
course I don't want to suggest that this is children's play; e.g., I
haven't worked seriously on the palm detection part up to now (I cannot
do that, because I don't have "real" problems with accidental touches).
Many things that may sound trivial first may turn out to be intricate
(e.g., how do you distinguish a two-finger click from a click-and-drag
action? This might need a timeout. Perhaps Mac users can help here ...)
On 12/03/2015 12:20 AM, Ulf Brosziewski wrote:
The diffs below contain a complete and extensive rewrite of the
input-processing parts of wsmouse and the interface it provides to
the hardware drivers. It prepares the support for various kinds of
multitouch input, as well as an extended support for touchpads by
wsmouse.
Tests for regression with all kinds of "pointing devices" would be
welcome. Only a small set of touchpads and USB mice is available to
me, which is a somewhat uncomfortable situation when you are working
on things like this.
Please note that the first diff is for the synaptics driver in
xenocara, the rest is for the kernel. Patching that driver will be
necessary if you test with touchpads (and compiling it requires
the modified version of wsconsio.h in /usr/include/dev/wscons/).
In most drivers I have made only short and trivial changes, the
Elantech-v4 part of pms is the only one that makes full use of the
new MT functions.
Unlike the basic input layer, which I hope is already fairly stable,
the in-kernel touchpad support is in a more experimental stage. If
you have a Synaptics, ALPS, or Elantech-v4 touchpad, you could test
it by adding this xorg.conf to /etc:
Section "InputClass"
Identifier "wstpad"
Driver "ws"
MatchIsTouchPad "true"
EndSection
Only a default configuration will be available with this. It enables
two-finger-scrolling and a lower soft-button area for clickpads, and
two-finger- or edge-scrolling for touchpads (support for tapping and
upper soft-button areas is implemented, but it won't be enabled by
the automatic configuration). If this works, it would also be
interesting for me to know whether the defaults for pointer speed
and acceleration are decent.
Of course I'm not only interested in tests. Questions, comments,
suggestions, and any kind of help would also be welcome.
[...]
