On Tue, 10 Apr 2018 12:37:15 +0300 Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Mon, 9 Apr 2018 12:12:49 +1000
> Peter Hutterer <peter.hutte...@who-t.net> wrote:
>
> > On Fri, Mar 23, 2018 at 02:00:56PM +0200, Pekka Paalanen wrote:
> > > From: Pekka Paalanen <pekka.paala...@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 <l...@collabora.com>
> > > Signed-off-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>
> > > ---
> > > libweston/compositor.h | 21 +++++++++++++++-
> > > libweston/input.c | 60
> > > ++++++++++++++++++++++++++++++++++++---------
> > > libweston/libinput-device.c | 11 ++++++++-
> > > 3 files changed, 79 insertions(+), 13 deletions(-)
> > 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.
On second thought, even adding just
struct weston_point_global_double {
double x;
double y;
};
would be touching quite many places, and it would prompt me to add
struct weston_point_global_fixed {
wl_fixed_t x;
wl_fixed_t y;
};
which would touch even more that I'd probably be touching almost all
APIs there are. Those would need to be complemented with struct
weston_point_surface_{double,fixed} as well.
So if you don't mind, I would leave that yak for another time.
But, maybe I can start with struct weston_2d_normalized_range_coords
since that's not used elsewhere at all. If I can figure out a bit
shorter name... weston_point2d_output_normalized...
Thanks,
pq
pgpcCxHKN2sWP.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
