[PATCH 1/7] litest: add a generic multitouch screen

[Peter Hutterer]

On Thu, Jun 11, 2015 at 10:06:37PM +0200, Andreas Pokorny wrote:
> Hi,
> 
> On Thu, Jun 11, 2015 at 8:04 AM, Peter Hutterer <peter.hutterer at who-t.net>
> wrote:
> 
> > [...]
> > > +static struct input_absinfo absinfo[] = {
> > > +     { ABS_X, 0, 1500, 0, 0, 0 },
> > > +     { ABS_Y, 0, 2500, 0, 0, 0 },
> >
> > out of interest: is his from a real touchscreen? no resolution?
> >
> 
> Yes and not an exception. I havent seen a non-zero resolution yet.

these devices should get resolution entries in the hwdb then, it'll make
life a lot easier and more predictable for callers.
http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-evdev.hwdb
I'm thinking we should put at least a bug log in if a touchscreen device
comes up with no resolution and we have to fake it. after all, our API
claims we provide data in mm by default.

> > [...]
> > >  enum litest_device_feature {
> > > @@ -156,6 +157,9 @@ enum litest_device_feature {
> > >       LITEST_ABSOLUTE = 1 << 13,
> > >       LITEST_PROTOCOL_A = 1 << 14,
> > >       LITEST_HOVER = 1 << 15,
> > > +     LITEST_PRESSURE = 1 << 16,
> > > +     LITEST_ELLIPSE_ORIENTATION = 1 << 17,
> > > +     LITEST_ELLIPSE_SIZE = 1 << 18,
> >
> > do we need two different flags for this? how many devices have major/minor
> > but not orientation?
> >
> 
> Hm to what I have access to all have major + pressure and a few add
> orientation and minor to that. And one exception that comes wih orientation
> but a minor value. Not sure what to make out of that one.. The orientation
> value is pretty acurate.. but without more information about the shape..
> 
> So if we only have major we assume a circular shape and there is no
> orientation. What about circle vs ellipse?

I saw that in one of the later patches, sorry, circular means major/minor
but no orientation. I guess that answers my question then, but this comment
was just for the test flags though, I don't think we need two separate flags
here, at least not until we have a significant amount of tests that need to
know the difference. a LITEST_TOUCH_ELLIPSE flag would be enough for any
touch device that goes beyond x/y and pressure.

As a general rule though, I go with "if the hw doesn't make sense, we ignore
it", so that device with minor but no major should simply be rejected, or at
least ignore the extended axes.

Cheers,
   Peter

 
> >
> > >  };
> > >
> > >  struct litest_device {
> > > @@ -302,6 +306,18 @@ void litest_touch_move_two_touches(struct
> > litest_device *d,
> > >                                  double x1, double y1,
> > >                                  double dx, double dy,
> > >                                  int steps, int sleep_ms);
> > > +void litest_touch_pressure(struct litest_device *d,
> > > +                        unsigned int slot,
> > > +                        double pressure);
> > > +void litest_touch_orientation(struct litest_device *d,
> > > +                           unsigned int slot,
> > > +                           double orientation);
> > > +void litest_touch_major(struct litest_device *d,
> > > +                     unsigned int slot,
> > > +                     double touch_major);
> > > +void litest_touch_minor(struct litest_device *d,
> > > +                     unsigned int slot,
> > > +                     double touch_minor);
> > >  void litest_hover_start(struct litest_device *d,
> > >                       unsigned int slot,
> > >                       double x,
> >
> > I'm wondering if this is the best approach here, it would quickly become
> > unwieldly. Can we use the same approach as in the tablet-support branch,
> > where we supply an array with axes to override?
> >
> 
> Ok.