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 ? 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. > > > > > > > >[...] -- Matthieu Herrb
pgpQ4NsVdXLhK.pgp
Description: PGP signature
