On Thu, Mar 19, 2015 at 11:45:16AM +0200, Pekka Paalanen wrote: > On Thu, 19 Mar 2015 07:13:18 +1000 > Peter Hutterer <[email protected]> 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 <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
