ginput: Touch invert/flip

[Endalvik]

I have a LCD panel that implements capacitive touch using the FT5406.  Oddly, the touch Y axis is inverted/flipped relative to the display Y axis.  To compensate for this, I would like to add an axis invert/flip option.

I cannot find any such option while inspecting the code for ginput / gmouse / FT5x06 driver, etc -- though perhaps I am simply missing it.

Can you recommend how best to add this too the code?  For instance, would it be appropriate to add "flipY" (and "flipX") flags to the GMouse struct, and then allow read_xyz() to perform the inversion arithmetic? 

Thanks!

[Endalvik]

Update:  working around this by creating and retrieving hard-coded calibration data, per the wiki.  I am not needing general calibration, as the touch/LCD are physically matched (aside from the flipped/inverted Y).  Now have this in my custom board_framebuffer.h:

// Force in calibration data, to compensate for hardware configuration
float calibrationData[] = {
	1,			// ax:  no change
	0,			// bx:  no change
	0,			// cx:  no change
	0,			// ay
	-1,			// by:  flip Y axis
	SCREEN_HEIGHT-1	// cy:  flip Y axis
};

gBool LoadMouseCalibration(unsigned instance, void *data, gMemSize sz)
{
	if( sz != sizeof( calibrationData ) || instance != 0 ) {
		return FALSE;
	}

	memcpy( data, (void *)&calibrationData, sz );

	return gTrue;
}

However, this is not ideal as now every single touch/movement now has costly floating-point math overhead.

I am open to suggestions on a lower-overhead (yet consistent) way of handling touch hardware that is flipped/inverted.

Thanks.

Edited December 3, 2018 by Endalvik

[inmarket]

The trouble here is that you get any two devices from different sources and they will possibly have different alignments between the touch screen and the display screen. To make things worse very few devices are well aligned physically. Also the resolution of the display seldom matches the resolution of the touch panel.

What this means is that floating (or fixed) point multiplication is needed in 99% of cases whether or not that is via fixed calibration settings. Despit this we have implemented fixed alignment code as an option for some drivers but that doesn't work for all devices (as you have already discovered) due to the reasons above.

In V3 we are looking at providing better fixed alignment code that caters for more orientations but for now the correct solution is either a custom driver hack or, preferably, the fixed calibration matrix.