Skip to content

Conversation

glennra
Copy link

@glennra glennra commented Sep 13, 2025

Previously was using the already mapped x coord to compute the new y coord

Previously was using the already mapped x coord to compute the new y coord
@kdschlosser
Copy link
Collaborator

kdschlosser commented Sep 14, 2025

the mapping is not wrong. Your touch screen is more than likely connected wrong to the IC. Is this with an XPT2046 touch screen? If it is it's very common to have them connected incorrectly to the touch IC and it has been seen before.

What you need to do is the following..

if not indev.is_calibrated:
    indev.calibrate()
    indev._cal.mirrorX = not indev._cal.mirrorX
    indev._cal.mirrorY = not indev._cal.mirrorY

where the mirrorX and mirrorY you use to slip the axis that is incorrect.

If you have an issue with the X and Y axis's being flip flopped meaning x, y = y, x then you pass a startup rotation to the indev driver.

@glennra
Copy link
Author

glennra commented Sep 14, 2025

The mapping data is correct but there is a bug in the implementation of the mapping calculation.
In this code:

           x = int(round(x * cal.alphaX + y * cal.betaX + cal.deltaX))
           y = int(round(x * cal.alphaY + y * cal.betaY + cal.deltaY))

The x value used to compute y is the scaled value from the previous line. It should be the value that is passed to the function. The PR fixes this.

@glennra
Copy link
Author

glennra commented Sep 14, 2025

I don't see why the mirroring is necessary if the calibration function is used. The affine transformation that the calibration function does should take care of that. It would only be necessary to use the mirror parameters if swapping the calibration data to another board that has reversed connections.

@kdschlosser
Copy link
Collaborator

HOLY shit, you are right.. I cannot believe I messed that up like I did. By setting x it messed up the value of x for the y coordinate.

I knew that the way I was doing the calibration should have handled any mirrored axis and any rotation should there be any but for some reason it didn't work 100% correctly. I stared at it for days and could not see the problem.

Thank you for taking the time to point that out to me. The only thing that I ask is that you add a comment as to why the values are stored like they are so in the future myself or perhaps someone else doesn't go and change it for some reason.

I thank you very much for locating and correcting this issue. It just needed another set of eyeballs that was familiar with using a matrix to handle the calibration.

@kdschlosser
Copy link
Collaborator

I know I am being kind of a pain but not as a docstring. docstrings consume memory because they get loaded as a variable. Comments also take up some memory but not as much as a docstring does. Just a simple one liner that states the backups of the XY need to exist because they are both used in the X and Y decoding of the calibration data... Just so I don't forget and do the dumbass thing of changing it back for some reason.

You can also add your username to the comment as well if you like. This has been a long standing issue and I really do tip my hat to you for finding it. I am super stoked about it being fixed and being able to remove the startup rotation and also the mirrors from the calibration design.

@glennra glennra force-pushed the fix-touch-coords-mapping branch from 1d6d12c to 2cfd967 Compare September 15, 2025 05:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants