On 12/16/2015 03:11 PM, Matthieu Herrb wrote:
On Wed, Dec 16, 2015 at 02:32:44AM +0100, Ulf Brosziewski wrote:
Ping? No further thoughts on this, no tests? Do I have to conclude that
most people are happy with wsmouse as it is?
Hi,
I'd like to see things move forward, but I currently lack time to do
anything serious on this.
One thing is not clear to me after looking (quickly) at your patch and
trying it: how does this work integrate with the libinput port ?
I hope it keeps various options open. Something like the wsmouseinput
part, which tracks input states and produces events, is necessary
anyway, would you agree with that? Quite generally, there might be three
strategies for porting libinput:
1) We could try to make a port with a minimal change of the libinput
sources. I'm afraid this would require making our input framework
"libinput-compatible" and trying to rebuild at least a half of evdev.
2) We could try to separate the "reusable" parts of the libinput code
and replace the rest with new developments. I don't know what the
ratio would be, and whether the advantages would outweigh the
difficulties.
3) We provide a "thin" libinput layer that supports its API and is
backed by extended kernel functionality. This might be the most
flexible solution. Various mixtures of 3) and 2) will also be
possible.
Some work on a port that aims at 3) has already been done, and the
"touchpad extension" in my diff (wstpad) could support such a
solution.
With or without wstpad, it will be necessary to extend the event
system, and probably not only with a zoo of new (MT) type codes.
The wsmouse_configure() function and the struct wsmousehw might be
a base for handling extended informations about the devices. Perhaps
it isn't well-structured, and it will change in the future; but both
the basic MT suppport as well as wstpad already needed more than
wsconsio provides.
Using ws with touchpads isn't intended to be the end of the story
in this form. An unchanged ws isn't ideal, e.g., with respect to things
like acceleration and deceleration (I had to add a "deceleration"
feature because least the default acceleration profiles don't work well
with touchpads; but this means that similar and related operations are
scattered between distinct layers).
From what I understand from libinput, it moves a lot of the code that
maps low-level events to higher-level X events (for multi-touch, but
also for features like 2 fingers scrolling or side scrolling) from the
kernel to libinput itself.
With libinput, xf86-input-ws should be replaced by xf86-input-libinput
and there is no need to hack on xf86-input-ws anymore.
I've the impression that here you're adding this code to the kernel.
Please correct me if I'm wrong.
There is also the fact that I'm conviced that xinput (and libinput)
needs more information about the individual input device than what is
currently exposed through wsconsio. This is probably even more true
for multi-touch devices, since they have such a large set of possible
features..
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.
[...]
