As people might want to know what they have worked for, it's probably time for a summary of the first test results and my conclusions. (But please don't get that wrong: more tests and reports are and will be welcome.)
Hardware: Most tests were made with (PS/2) Synaptics touchpads, and it seems there are no problems with common models of "OpenBSD laptops". Few quirks and bugs have been reported for older and less common ones, and concern things that should be handled by the hardware driver. Alps and Elantech models are rare, and it looks like most Mac users are on holiday. Driver mechanisms: No serious problem has come up. It has been observed that there are (too) long delays between the start of a scroll gesture and the first scroll event. I'm already testing an improved version of the handler. There will still be a short delay, because it reduces the risk that you produce scroll events unintentionally. Features: Not surprisingly, some people are missing certain features. What has been mentioned is 1) "disable-while-typing", 2) edge areas (where initial contacts don't move the pointer or generate tap events), 3) multi-finger clicks, and 4) "coasting" (that is, scrolling continues for some time after the scrolling fingers have been lifted). Up to now my impression is that 1) and/or 2) could be prominent, maybe 3). However, there are no decisions about additional features yet, each one would need some care. 1) and 2) are different approaches to the same task: suppressing outputs of accidental contacts, usually palm or thumb contacts, so in this context one might also think of: 5) palm and thumb detection based on contact width, pressure, and other attributes, perhaps. 1) is based on a simple principle, but it needs coordination with another driver, and I am not sure whether it is a good solution, or despair. What's a reasonable timeout here? If it's too short, it only mitigates the problem, if it's too long, it can be a nuisance. 5) might work well for some users, with some touchpads, but it may be difficult to find useful generalizations. I'm currently checking variants of 2), the basic mechanism is already present in the driver (it's required for software buttons and edge scroll areas). But again, it's too early for conclusions, and surely we want to avoid a patchwork of half-general and half-successful solutions. Default configuration: The defaults, including the "hidden" ones, seem to be acceptable for many models. I will increase the default scroll speed (moderately). In some cases, the height of the button area on clickpads is problematic. This is not as trivial as it may seem. Coordinate limits are not always correct, and resolution values can be unreliable - if they are present at all. There is actually a good deal of guess work in the configuration. Improving that will need more work on the hardware drivers. As I have written, not all touchpad drivers cooperate with the input driver up to now. I hope this will change soon. It's not ready yet, but some work on imt/hidmt has already been done, with help of Remi. Thanks again for the friendly, competent, and helpful feedback! On 07/31/2017 11:02 PM, Ulf Brosziewski wrote: > In the long run the synaptics driver, which handles touchpad inputs in > X, may be a dead end of the input framework, and it's time to prepare > an alternative. The kernel contains an internal touchpad input driver > now, it's a part of wsmouse(4). It provides standard features - > two-finger/edge scrolling, software buttons for clickpads, tapping - > and various kinds of plankton required for usability. > > If you have a new snapshot (from July 27 or later) on a laptop with a > Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with > tests [...]
