[RFC] libinput configuration interface

[Peter Hutterer]

On Thu, Feb 20, 2014 at 12:21:53PM +0600, Alexander E. Patrakov wrote:
> 20.02.2014 11:14, Peter Hutterer wrote:
> >On Wed, Feb 19, 2014 at 11:55:28AM +0600, Alexander E. Patrakov wrote:
> >>19.02.2014 04:52, Peter Hutterer wrote:
> >>>The set of touchpad patches I sent out recently already handle this by
> >>>default. When the physical clickpad button is depressed, the driver picks
> >>>the finger that is pressing the button (sometimes guessing, but hey...).
> >>>That finger cannot control the pointer movement until the button is released
> >>>again.
> >>>
> >>>In your specific use case, the driver would see two touchpoints and it will
> >>>select the one closer to the bottom edge as the pressing finger (i.e. your
> >>>thumb). The index finger can still move while the button is down.
> >>
> >> 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
> >
> >can you expand on the 100% comment here? is the touchpad too small for
> >anything else?
> 
> The height of the touchpad is too small (the width is OK). See e.g. http://www.blogcdn.com/www.engadget.com/media/2013/06/dsc00149-1370365891.jpg
> 
> (Just to avoid confusion: I have a Sony Vaio Z23A4R, don't have a
> Sony Vaio Duo 13, and don't have a Sony Vaio Pro 13. As for my
> accent on Sony laptops, that's only because there is a Sony shop
> nearby.)

quite frankly, I think this touchpad is one where you (the user) would have
to get used to tap-and-drag and two-finger tapping or two-finger clicking
instead virtual button areas. I think that'd be a much better fit for a
touchpad like this.

Cheers,
   Peter

> >>attention to changes in pressure and filters any spurious movement
> >>(i.e. any movement that is combined with significant pressure
> >>changes) out.
> >>
> >>But hey, Sony in their new laptops started to ignore the problem
> >>under Windows, too, so I think I just have to swallow this and/or
> >>use my Bluetooth mouse.
> >
> >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.
> 
> >the xorg synaptics driver has for historical reasons and portability a
> >different approach to finger tracking and some of the misbehaviours are
> >easier to fix now.
> >
> >The proposed patches have a different approach to the above:
> >1 - would be recognised as touchpoint, since no other finger is active it is
> >designated as the pointer-moving touchpoint
> >2 - second finger recognised, but not assigned as pointer-moving. Movements
> >on that finger have no effect, unless 2-finger scrolling is triggered.
> >3 - no effect, finger is not moving
> >
> >So really, the goal here is that whatever the motion we see in 2 and 3 is to
> >not go past the "trigger 2-finger scrolling" threshold.
> 
> Yes, I think we agree on that.
> 
> >I do have a set of patches not yet ported for the virtual buttons and they
> >add additional tracking, so that a finger that starts (and stays) inside a
> >softbutton area won't contribute to movements, but as you said above that
> >may not work with the vaio.
> 
> Yes, I would like to see that on my Z23A4R (and it matches the
> Windows default), but users of Duo 13 definitely would not want that
> enabled on their laptops. As for Sony Vaio Pro 13, this feature
> won't hurt, but, as I have already said, does not match the Windows
> default there.
>