[PATCH v2] protocol: Extend wl_touch with touchpoint shape event

[Peter Hutterer]

On Mon, Apr 18, 2016 at 04:49:46PM +0200, Andreas Pokorny wrote:
> Hi,
> Some questions below..
> 
> On Wed, Apr 6, 2016 at 11:52 PM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
> 
> > On Wed, Apr 06, 2016 at 10:17:35AM -0700, Dennis Kempin wrote:
> > > On Tue, Apr 5, 2016 at 5:26 PM, Peter Hutterer <peter.hutterer at who-t.net>
> > wrote:
> > > > On Tue, Apr 05, 2016 at 01:09:31PM -0700, Dennis Kempin wrote:
> > > >> [...]
> > > >> +      </description>
> > > >> +      <arg name="id" type="int" summary="the unique ID of this touch
> > point"/>
> > > >> +      <arg name="major" type="fixed" summary="length of the major
> > > >> axis in surface coordinates"/>
> > > >> +      <arg name="minor" type="fixed" summary="length of the minor
> > > >> axis in surface coordinates"/>
> > > >> +      <arg name="orientation" type="fixed"
> > > >> +           summary="angle between major axis and surface x-axis in
> > degrees"/>
> > > >> +    </event>
> >
> 
> Jumping on the major/minor train. Is there no interest in pressure values?
> It seems that more accurate touchscreens that may offer reproducible
> pressure values
> become mainstream..

separate value -> separate event :)

 
> > > [...]
> 
> > > Maybe we could include a fallback event for devices that do not have
> > > good support?
> > > One that would only use a single value to describe the size of a
> > > touch, normalized
> > > to 0..1. In practice, I do not think we could put any more requirements
> > on this
> > > value. There is no way for us to tell how tell if a device is using
> > > the full range
> > > (0 to reported max axis value), and in a bad case we might end up with
> > that
> > > size being in the range of 0 to 0.1.
> > >
> > > Let me know what you think about this.
> >
> > I'm mostly thinking about how to enable this in libinput from a technical
> > perspective, and the obvious solution would be whitelisting or blacklisting
> > devices, combined with the calibration you use as well.
> >
> > the fallback wouldn't be normalized but simply skipping it where we can't
> > be
> > sure. to do that, we need to do one thing though: split up the events into
> > area and orientation as separate events. we can send orientation even when
> > the area is unknown.
> >
> > how does that sound?
> >
> 
> Are you referring to libinput events or wayland events here? Why would
> splitting the events help?

it's better to not send an event than sending magic values that
the client then needs to interpret as "undefined". so splitting them up
gives us the option of sending only orientation on those touchpads where the
major/minor values are garbage.
orientation and skip the major/minor event.

> I have also seen touchscreens just offering a major axis and an
> orientation. That is an edge
> case but even there we could have finger-heuristic to estimate a minor
> value..

that is a case where IMO assuming it's a circle is sufficient. but this
assumption should be on the lower level anyway, not in wayland.

Cheers,
   Peter

> @Dennis: I am curious how complex the contact size calibration function in
> chrome os is.
> 
> regards
> Andreas