<div dir="ltr">Hi,<br>Just a heads up on the problem I experience that I thought would be related to what you described.<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 2, 2015 at 12:50 PM, Andreas Pokorny <span dir="ltr"><<a href="mailto:andreas.pokorny@canonical.com" target="_blank">andreas.pokorny@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">[...]<br><div class="gmail_quote">On Tue, Sep 1, 2015 at 8:30 AM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[...]<span class=""><br>
but first up, I have to ask: how did you test this, do you have an<br>
implementation higher up in the stack that makes use of this? The API looks<br>
generally ok now, but once I started testing it it didn't turn out too well.<br></span></blockquote><div><br></div><span class=""></span><span class=""><div>[...]<br>
> + break;<br>
> + case ABS_MT_TOUCH_MAJOR:<br>
> + current_slot->available_data |= TOUCH_SLOT_DATA_MAJOR;<br>
> + current_slot->area.major = e->value;<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">the handling of the has_major/minor/orientation isn't correct. if a device<br>
has the axis, you can get the current per-slot value on device startup.<br>
the value remains valid until overwritten by a new value on the device. so<br>
libinput_event_touch_has_major() doesn't tell us whether a specific event<br>
has a major axis, but rather whether a device do the axis at all, i.e. it's<br>
either always true or always false. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
the API could be libinput_device_has_... but I think the per-event API is<br>
better. the current implementation is broken though, just add a printf to<br>
event-debug and you'll see how we don't know major/minor until we get an<br>
event for each.<br></blockquote></span></div></div></div></blockquote><div><br></div><div>I think I misunderstood you here. You meant I should instead of tracking slot changes check for mt axes?<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><div><br></div></span><div>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. <br></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>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. <br></div></div></div></div></blockquote><div><br></div><div class="gmail_quote">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.. <br><div><br></div><div>regards<br></div><div>Andreas<br></div></div></div><br></div></div>