[PATCH weston 0/5] fix fbdev transforms

[Peter Hutterer]

On Thu, Mar 19, 2015 at 11:45:16AM +0200, Pekka Paalanen wrote:
> On Thu, 19 Mar 2015 07:13:18 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
> > On Wed, Mar 18, 2015 at 01:14:52PM +0200, Pekka Paalanen wrote:
> > > On Wed, 18 Mar 2015 11:45:01 +0100
> > > Thilo Cestonaro <thilo at cestona.ro> wrote:
> > > 
> > > > Hey!
> > > > 
> > > > 
> > > > > Is it broken only on fbdev or DRM also?
> > > > 
> > > > DRM is the same as Fbdev. The touch doesn't have the correct 
> > > > orientation, but I can use weston-simple-touch to have a windows paint 
> > > > simulation with just one brush and color :)
> > > > 
> > > > 
> > > > > Can you try to use weston-simple-touch to see if the touch input is
> > > > > just missing the rotation of the rotated screen?
> > > > 
> > > > Jup, touch is missing the correct orientation. with weston-simple-touch 
> > > > I see red dots everywhere but not there, where I touch :).
> > > > 
> > > > 
> > > > > If you don't rotate the screen, is touch working ok then?
> > > > 
> > > > Jup, without rotation it is working correctly.
> > > 
> > > Ok, so it's just a missing output transformation with the touchscreen
> > > setup.
> > > 
> > > Peter, is one supposed to account for screen rotation already in the
> > > touchscreen calibration, or should the compositor combine the
> > > calibration with the current output rotation/flip? I mean, how would
> > > this translate into libinput API usage and the touchscreen calibration
> > > matrix from... udev?
> > > 
> > > I assume we should do the latter in case some compositor can change the
> > > rotation at runtime (tablets etc.).
> > 
> > yep, the calibration is a static thing (which is why we allow it to be set
> > by udev). And any calibration you set overwrites the udev one, you can still
> > get that one later with libinput_device_config_calibration_get_default_matrix()
> > The idea is that calibration need to only be applied once, then the
> > compositor can forget about it.
> > 
> > if you're rotating the output that this device is associated with,
> > you need to also rotate the input coordinates. The data from libinput is
> > already calibrated, so it's just the pure rotation you need to apply.
> > Do not rotate in the calibration matrix, unless the touchscreen is
> > physically mounted with that rotation.
> > 
> > Does that make sense?
> 
> Hi Peter,
> 
> I think it does, yes. Just to reiterate, libinput will provide absolute
> coordinates in the output space, and the compositor needs to convert
> that to its own global space by applying the (inverse of) output
> transformation matrix (global->output pixel coords). Right?

close enough. libinput provides absolute coordinates in mm and/or scaled to
the screen dimensions passed into
  libinput_event_touch_get_x_transformed()
  libinput_event_touch_get_y_transformed()
it doesn't know about output dimensions as such. The compositor needs to
then convert that into the appropriate global space like you said.

Cheers,
   Peter

> I haven't looked at the Weston code, but Thilo says it's broken. Thilo,
> could you file a bug with all this information against Weston? If there
> isn't one open already, that is.
> 
> 
> Thanks,
> pq