Touch events appear offset with presence of a second monitor

Peter Hutterer peter.hutterer at who-t.net
Sun Jan 4 18:27:22 PST 2015


On Sun, Jan 04, 2015 at 08:46:17PM -0500, Ben Gamari wrote:
> 
> Hi Peter,
> 
> Peter Hutterer <peter.hutterer at who-t.net> writes:
> 
> > On Fri, Jan 02, 2015 at 01:49:01PM -0500, Ben Gamari wrote:
> > 
> [snip]
> 
> >> If I place the monitor to the right of the panel, touches map to the
> >> panel as expected. This isn't terribly surprising: the input presumably
> >> has no idea that the touch device has any particular relation to the
> >> panel so the input device events are mapped to a location relative to
> >> the origin of the screen, not the panel. How is this situation supposed
> >> to be handled? Is ensuring that input devices and output geometries
> >> remain consistent left up to higher layers of the stack? This would be
> >> straightforward if xinput transformation matrices could encode
> >> translations; unfortunately it appears that they can not.
> >
> > yes, supposed to be handled by the rest of the stack. the X server doesn't
> > change the matrix, it only reads it. and translations are handled on
> > absolute devices, but they're just ignored for relative devices.
> >
> Hmm, still not sure I see how translations are handled. How does the
> server know which output the input device is supposed to "follow"?

it doesn't. the server takes all outputs' offsets and dimensions and merges
it into one area. then it maps the transformation matrix to that area and
re-converts that into screen coordinates for the event data, etc.

if you want to map a device to the right of two identically sized monitors,
you need a matrix of 
  0.5 0 0.5
  0   1 0
  0   0 1

it's the client's job to guess which monitor is which and calculate the
matrix accordingly.

Cheers,
   Peter

> Interestingly enough, my touchscreen correctly reports itself as an
> absolute device and yet, as reported above, still doesn't handle
> translations properly (see evemu output below).
> 
> 
> >> It does appear, however, that some component in the stack is updating
> >> the input transformation matrix of the input device when the output
> >> geometry is invoked. For instance after I light up the external display
> >> on either the right or left side of the panel the transformation matrix
> >> for the touch screen is,
> >> 
> >>     Coordinate Transformation Matrix (141):	0.500000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
> >> 
> >> Unfortunately, whatever is doing this does not reset the transformation
> >> matrix when the external monitor is disabled, resulting in the input
> >> events to be incorrectly scaled (e.g. a touch event on the right edge of
> >> the panel places the cursor at the middle of the screen). Does anyone
> >> know component of the stack is responsible for this update and why it
> >> fails to handle the `--off` case properly?
> >
> > gnome-settings-daemon most likely, file plugins/common/gsd-device-mapper.c
> >
> Thanks for the pointer!
> 
> Cheers,
> 
> - Ben
> 


More information about the xorg mailing list