[PATCH libinput] libinput: add orientation and size of touch point and pressure to the API

[Andreas Pokorny]

Hi,
Just a heads up on the problem I experience that I thought would be related
to what you described.

On Wed, Sep 2, 2015 at 12:50 PM, Andreas Pokorny <
andreas.pokorny at canonical.com> wrote:

> [...]
> On Tue, Sep 1, 2015 at 8:30 AM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
>
>> [...]
>> but first up, I have to ask: how did you test this, do you have an
>> implementation higher up in the stack that makes use of this? The API
>> looks
>> generally ok now, but once I started testing it it didn't turn out too
>> well.
>>
>
> [...]
> > +                     break;
> > +             case ABS_MT_TOUCH_MAJOR:
> > +                     current_slot->available_data |=
> TOUCH_SLOT_DATA_MAJOR;
> > +                     current_slot->area.major = e->value;
>
> the handling of the has_major/minor/orientation isn't correct. if a device
>> has the axis, you can get the current per-slot value on device startup.
>> the value remains valid until overwritten by a new value on the device. so
>> libinput_event_touch_has_major() doesn't tell us whether a specific event
>> has a major axis, but rather whether a device do the axis at all, i.e.
>> it's
>> either always true or always false.
>>
>
>> the API could be libinput_device_has_... but I think the per-event API is
>> better. the current implementation is broken though, just add a printf to
>> event-debug and you'll see how we don't know major/minor until we get an
>> event for each.
>>
>
I think I misunderstood you here. You meant I should instead of tracking
slot changes check for mt axes?


> With my touchscreens I get major and minor on the first down. But after
> looking at the output of the tool again, it seems that the down event does
> not have those values. Instead it still holds stale values from the last
> owner of the slot. I am looking into that now. In previous versions of the
> patch I reset everything when the tracking_id is itself reset to -1. The
> current code (modulo that bug) assumes that with the mt protocol you will
> always have valid data for an axis available. There should not be a need to
> reset individual values. So yes if the touch screen supports a certain axis
> libinput_touch_event_has_ will indicate 1 on each down or move event even
> when not changed during that move or down action.
>

That problem of stale values occured because one of that specific device
driver emits EV_KEY BTN_TOOL_FINGER (and also BTN_TOUCH) just right after
assigning a new tracking id, and before any slot data is provided. libinput
runs through evdev_flush_pending and emits a down event, with whatever is
inside the slot from the last event.



> I have no objection to go back to the previous behavior and reset on
> ABS_MT_TRACKING_ID  = -1, since it wont make a difference to the user -
> code wise it seems more consistent.
>

Ok after looking at that specific device I do have objections to reset slot
data. As it is easy to make the protocol for example not transmit the
ellipse major value on a new tracking id if you manage to press in the same
way..

regards
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150902/ea32c26c/attachment-0001.html>