[PATCH weston 16/25] libweston: introduce notify_touch_cal() and doc

[Pekka Paalanen]

On Mon, 9 Apr 2018 12:12:49 +1000
Peter Hutterer <peter.hutterer at who-t.net> wrote:

> On Fri, Mar 23, 2018 at 02:00:56PM +0200, Pekka Paalanen wrote:
> > From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> > 
> > notify_touch_cal() is an extended form of notify_touch(), adding
> > normalized touch coordinates which are necessary for calibrating a
> > touchscreen.
> > 
> > It would be possible to invert the transformation and convert from
> > global coordinates to normalized device coordinates in input.c without
> > adding this API, but this way it is more robust against code changes.
> > 
> > Recovering normalized device coordinates is necessary because libinput
> > calibration matrix must be given in normalized units, and it would be
> > difficult to compute otherwise. Libinput API does not offer normalized
> > coordinates directly either, but those can be fetched by pretending the
> > output resolution is 1x1.
> > 
> > Anticipating touch calibration mode, the old notify_touch() is renamed
> > into a private process_touch_normal(), and the new notify_touch_cal()
> > delegates to it.
> > 
> > Co-developed by Louis-Francis and Pekka.
> > 
> > Cc: Louis-Francis Ratté-Boulianne <lfrb at collabora.com>
> > Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> > ---
> >  libweston/compositor.h      | 21 +++++++++++++++-
> >  libweston/input.c           | 60 ++++++++++++++++++++++++++++++++++++---------
> >  libweston/libinput-device.c | 11 ++++++++-
> >  3 files changed, 79 insertions(+), 13 deletions(-)
> > 

> > -/**
> > - * notify_touch - emulates button touches and notifies surfaces accordingly.
> > - *
> > - * It assumes always the correct cycle sequence until it gets here: touch_down
> > - * → touch_update → ... → touch_update → touch_end. The driver is responsible
> > - * for sending along such order.
> > - *
> > - */
> > -WL_EXPORT void
> > -notify_touch(struct weston_touch_device *device, const struct timespec *time,
> > -	     int touch_id, double double_x, double double_y, int touch_type)
> > +static void
> > +process_touch_normal(struct weston_touch_device *device,
> > +		     const struct timespec *time, int touch_id,
> > +		     double double_x, double double_y, int touch_type)  
> 
> IMO just process_touch() is better, otherwise it's more confusing ("wait?
> why is this normal? and what's not normal? or is this an abbreviation of
> normalized?")

Ok.

> >  {
> >  	struct weston_touch *touch = device->aggregate;
> >  	struct weston_touch_grab *grab = device->aggregate->grab;
> > @@ -2423,6 +2416,51 @@ notify_touch(struct weston_touch_device *device, const struct timespec *time,
> >  	}
> >  }
> >  
> > +/** Feed in touch down, motion, and up events, calibratable device.
> > + *
> > + * It assumes always the correct cycle sequence until it gets here: touch_down
> > + * → touch_update → ... → touch_update → touch_end. The driver is responsible
> > + * for sending along such order.
> > + *
> > + * \param device The physical device that generated the event.
> > + * \param time The event timestamp.
> > + * \param touch_id ID for the touch point of this event (multi-touch).
> > + * \param double_x X coordinate in compositor global space.
> > + * \param double_y Y coordinate in compositor global space.
> > + * \param norm_x Normalized device X coordinate in calibration space.
> > + * \param norm_y Normalized device Y coordinate in calibration space.
> > + * \param touch_type Either WL_TOUCH_DOWN, WL_TOUCH_UP, or WL_TOUCH_MOTION.
> > + *
> > + * Coordinates double_x and double_y are used for normal operation.
> > + *
> > + * Coordinates norm_x and norm_y are only used for touch device calibration.
> > + * If and only if the weston_touch_device does not support calibrating,
> > + * norm_x and norm_y must be WESTON_INVALID_TOUCH_COORDINATE.
> > + *
> > + * The calibration space is the normalized coordinate space
> > + * [0.0, 1.0]×[0.0, 1.0] of the weston_touch_device. This is assumed to
> > + * map to the similar normalized coordinate space of the associated
> > + * weston_output.
> > + */
> > +WL_EXPORT void
> > +notify_touch_cal(struct weston_touch_device *device,  
> 
> this should be notify_touch_normalized() because that's what the extra
> values are. That calibration affects those is just an implementation detail.
> 
> Also, at this point I can only say creating structs for each coordinate type
> in libinput has helped greatly in understanding what exactly you're dealing
> with at any point in time. see libinput-private.h:
> 
> /* A coordinate pair in device coordinates */
> struct device_coords {
>         int x, y;
> };
> 
> /* A dpi-normalized coordinate pair */
> struct normalized_coords {
>         double x, y;
> };
> 
> /* A pair of coordinates normalized to a [0,1] or [-1, 1] range */
> struct normalized_range_coords {
>         double x, y;
> };
> 
> 
> etc. These are passed through the various functions, so the compiler will
> tell you when you're passing a device coordinate into something that should
> take a [0, 1] normalized range. I cannot recommend this enough when you're
> dealing with more than one coordinate system.

That's a good idea indeed. I think I'll re-spin with that.


> > +		 const struct timespec *time, int touch_id,
> > +		 double x, double y, double norm_x, double norm_y,
> > +		 int touch_type)
> > +{

> > -	notify_touch(device->touch_device, &time, slot, x, y, touch_type);
> > +	if (weston_touch_device_can_calibrate(device->touch_device)) {
> > +		norm_x = libinput_event_touch_get_x_transformed(touch_event, 1);
> > +		norm_y =  libinput_event_touch_get_y_transformed(touch_event, 1);  
> 
> one space to many

Yup.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180410/8d01e4ea/attachment.sig>