On Fri, Feb 21, 2014 at 01:29:05AM +0600, Alexander E. Patrakov wrote: > 20.02.2014 12:21, I wrote: > >20.02.2014 11:14, Peter Hutterer wrote: > >>On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote: > >>> From my experience with the Sony touchpad (Vaio Z23A4R laptop), I'd > >>>say that it doesn't solve the whole problem. Here is what goes wrong > >>>with the old synaptics driver by default and can be worked around > >>>with AreaBottomEdge. > >>> > >>> Option "SoftButtonAreas" "4360 0 4000 0 2880 4359 3500 0" > >>> Option "AreaBottomEdge" "3500" > >>> > >>>1. I move the right-hand index finger on the touchpad, thus moving > >>>the pointer to the place where I want to click. > >>> > >>>2. I place the left-hand index finger into the virtual-button area, > >>>while still keeping the right finger on the touchpad. I cannot > >>>remove the right-hand finger: if I do that, while the contact area > >>>shrinks, its center also moves, and the driver picks that up. > >>> > >>>3. As I increase the pressure on the left-hand finger until the > >>>touchpad clicks, the contact area increases. Unfortunately, its > >>>center moves, too, and this can accumulate to ~2-3 pixels until it > >>>clicks. > >>> > >>>The important point is that the bad thing happens before the > >>>hardware button click, so the quoted solution totally misses the > >>>point. > >>> > >>>So we need something, either a sledgehammer solution in the form of > >>>ignoring all motion in the virtual button area (but that would break > >>>Sony Vaio Duo 13 because the only usable height of the virtual > >>>button area is 100% there), or some very good filter that pays > > >>couple of comments here: > >>2 is a synaptics bug that should really be fixed, the driver shouldn't be > >>that sensible - in fact there's probably something that can be done about > >>making the driver more sensible while the finger is moving and less > >>sensible > >>while the finger is still (just an idea, may not work for small > >>movements). there is also the option of using pressure to counteract > >>movements, i.e. a pressure change will increase the hysteresis to avoid > >>erroneous movements. If you have that many issues with the Sony, I really > >>recommend looking at the evdev-mt-touchpad patches I sent to this list, > >>it'll allow for things like that relatively simple. > > > >OK, I will build this on my laptop from git later today. > > Just did this, but have not looked at the code yet. Tested with > xf86-input-libinput, thus had no chance to configure anything > specific to libinput. If this has any chance of yielding different > results, I will retest with Weston on Saturday.
libinput currently exposes no configuration interfaces, so the only differences you may see is in pointer acceleration. > Software versions: > > * mtdev 1.1.4 (Gentoo) > * xorg-server 1.15.0 (Gentoo) > * libevdev from git, cf70d0 > * libinput from git, 128f98 + your 19 patches > * xf86-input-libinput from git, 761603 > > Hardware: Sony VAIO Z23A4R, the touchpad identifies itself as follows: > > I: Bus=0011 Vendor=0002 Product=0007 Version=01b1 > N: Name="SynPS/2 Synaptics TouchPad" > P: Phys=isa0060/serio1/input0 > S: Sysfs=/devices/platform/i8042/serio1/input/input4 > U: Uniq= > H: Handlers=mouse0 event3 > B: PROP=5 > B: EV=b > B: KEY=e520 10000 0 0 0 0 > B: ABS=660800011000003 > > Pointer movement works, but it is too slow by default on this > laptop. That is, a VERY quick swipe (not expected during normal work > and even during games) from left to right is just enough to move the > pointer across the entire screen (1920x1080). Setting constant > deceleration to 0.3 or 0.4 makes it more usable in terms of speed, > but this might be my personal preference, and I am not sure if the > constant deceleration is the correct knob here. I have not yet looked into pointer-accel fine-tuning on the touchpad or in xf86-input-libinput. What you're seeing is quite simliar to what I have here - it's slow but not unusable. Sorry, just haven't focused on that yet by any help would be appreciated. I don't think deceleration is the right nob here, but I can't remember what you need to tweak. Generally I try not to touch constant deceleration unless the device is a high-resolution device that sends way too many events. If you need to use a value 0..1 for CD then you're effectively using it to speed things up, the term "deceleration" should hint that this may not work perfectly :) > With the default constant deceleration (1.0), pointer movement is > very precise. It follows the finger equally well in all parts of the > touchpad and in all directions, as expected. I get no misplaced > clicks. > > With constant deceleration 0.3, this is not true. It works better in > the central part of the touchpad, but, when crossing the physical > border between the area for pointer movement (which is rough) and > the area for virtual buttons (which is smooth), it starts to behave > like a dirty mechanical mouse. Here is what I mean by that: hard to > move the cursor diagonally (i.e. there is a strong preference > towards horizontal or vertical movements), and the motion is uneven > if I move the finger slowly. The same applies to the top part of the > touchpad, although there is no sharp line where this appears. > > In both cases, there is no spurious pointer movement when putting > the finger on the touchpad or removing it. I.e., points 2 and 3 are > somehow already dealt with. > > Vertical two-finger scrolling works, but is way too sensitive both > with constant deceleration 1.0 and with 0.3. that's a xf86-input-libinput bug, Benjamin fixed that but I forgot to push. 761603d..bee8989 now, please re-test that. > Clicking works. If there are two fingers on the touchpad at the time > of clicking, it registers a right-click. As the touchpad cannot > track more than two touches, three-finger gestures don't work. OTOH, > I have read Documentation/input/multi-touch-protocol.txt: "Some > devices identify and/or track more contacts than they can report to > the driver." I have not yet tested whether this applies to my > touchpad, and whether it uses BTN_TOOL_TRIPLETAP. run evtest or evemu-record against the device, that'll tell you. Note that I haven't enabled the fake touch emulation for those devices yet, right now BTN_TOOL* is only treated as a touch on single-touch devices. so right now, you only get up to ABS_MT_SLOT maximum touchpoints. > Tapping and tap-and-drag are not usable. They require not tapping, > but knocking with force. So this points to the driver being > "miscalibrated" on the pressure axis. Can this also be the reason of > the low x/y sensitivity and "dirty mouse" feeling? that's a bit odd. I'd like to see an evemu-record output from that then. Currently I ignore pressure completely, so any touch should be detected. > Can I provide any objective data that would allow better sensitivity > calibration by default on this device? Touchpad data is always subjective :) it depends on finger size, conductivity and a whole bunch of other factors. what does help though is having evemu recordings of certain events. They may still be subjective but they're reproducible, allowing us to fine-tune based on a specific event sequence and then go from there. e.g. you can take a recording fo an example one-finger tap and then make sure that that always produces a tap event. if you build up a database of these events, you can cover events quite well for a multitude of devices and users. Cheers, Peter _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel