Jump to content
Sign in to follow this  
Endalvik

ginput: Touch invert/flip

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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 by Endalvik

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×