Jump to content
Sign in to follow this  

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? 


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.


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Create New...