[RFC] libinput configuration interface

Alexander E. Patrakov patrakov at gmail.com
Wed Feb 19 22:21:53 PST 2014


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.)

>> 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.

-- 
Alexander E. Patrakov


More information about the wayland-devel mailing list