Hi Jürgen
root@mx25-noah:~$> ts_calibrate
xres = 640, yres = 480
selected device is not a touchscreen I understand
Took 1 samples...
Top left : X = -1226698440 Y = 0
Took 1 samples...
Top right : X = -1226698440 Y = 0
Took 1 samples...
Bot right : X = -1226698440 Y = 0
Took 1 samples...
Bot left : X = -1226698440 Y = 0
Took 1 samples...
Center : X = -1226698440 Y = 0
ts_calibrate: determinant is too small -- 0.000000
Calibration failed.
root@mx25-noah:~$> export | grep TS
declare -x TSLIB_CALIBFILE="/etc/pointercal"
declare -x TSLIB_CONFFILE="/etc/ts.conf"
declare -x TSLIB_CONSOLEDEVICE="none"
declare -x TSLIB_FBDEVICE="/dev/fb0"
declare -x TSLIB_PLUGINDIR="/usr/lib/ts"
declare -x TSLIB_TSDEVICE="/dev/input/event0"
declare -x TSLIB_TSEVENTTYPE="INPUT"
Strange. With the same driver here:
I have taken the time and set up an temporary EC2 cluster machine to
quickly compile package from openembedded and it now works. The reason
for the incorrect build of the openembedded on this local development
machine is as of now completely unbeknown to me. Using the git HEAD tree
of openembedded and compiling the tslib and libts packages, installing
them on the device, helped me getting a partial success:
root@NesoLT:~ ts_calibrate
xres = 480, yres = 272
Took 127 samples...
Top left : X = 528 Y = 953
Took 127 samples...
Top right : X = 3598 Y = 1013
Took 127 samples...
Bot right : X = 3557 Y = 3258
Took 127 samples...
Bot left : X = 560 Y = 3233
Took 127 samples...
Center : X = 2034 Y = 2060
-17.849060 0.125239 0.000206
-21.600891 -0.001079 0.075981
Calibration constants: -1169756 8207 13 -1415636 -70 4979 65536
It now looks very similar to your output, of course with different
calibration values. Nevertheless, X11 does not care about the stored
adjustment values in /etc/pointercal; in fact, it does not even read it.
To be honest, I don't know if X11 is even supposed to read those values.
So, we are back at the drawing board:
What's working so far
---------------------
+ your driver works quite fine both in 2.6.x and 3.3-rcX kernel series
+ ts_calibrate works and sprinkles out some calibrations values to
/etc/pointercal
+ X11 boots up and the pointer is followed on touch, albeit with 5-10
pixel shift jitters effects and a non-linear distribution of screen edge
margins:
+---------------------------------+
| visible area |
| +---------------------------+ |
| | touchable area . | |
| | . | |
| | . | |
| | . | |
| | . | |
| | . | |
[ |....................x......| |
| | . | |
| | . | |
| | . | |
| | . | |
| | . | |
| | . | |
| | . | |
| | . | |
| | . | |
| | . | |
| | . | |
| +---------------------------+ |
| |
| |
+---------------------------------+
The deltas measuring the screen edge margins between the visible area
and the currently touchable area (dN for delta north, dS, dE, dW) are:
dN=10px, dE=8px, dS=14px, dW=45px
The 'x' marks the spot where the X11 graphic pointer seems exactly at
the right position (plus jitter of +-5-10px) of the pressure point of my
"sharp" pointing device. A movement in any direction from the 'x' slowly
shifts the X11 pointer with direction towards the 'x' relatively seen
from the pressure point in a non-linear (quasi-quadratic) manner until
it reaches the above mentioned deltas between the X11 pointer and the
effective pressure point at the corresponding edges. This leads me to
believe that there is something fishy going on with the circuit rather
than the driver. The oscilloscope shows some hairy signal interference
in the 50mV region, which, taking into account the mx25 12bit ADC and
the +3.3V touch driver max voltage and the 0.1815 pixel pitch of the
el-cheapo LCD could explain the screen edge shifts.
What's missing
--------------
+ proper calibration for my el-cheapo Chinese 640x480 touch screen, so
I can access the whole visible LCD view-plane with touch within X11 or
QT or both, ts_calibrate does not help at all in this case; at least it
does not crash anymore.
+ proper small PCB changes with the 10nF capacitors (as indicated by
mx25 data sheet) on the LCD connector panel (right now it's a quick and
dirty soldering job to check the signal noise reduction hypothesis)
While I completely agree that ts_calibrate and in general user space
should handle such issues, I currently didn't manage to find a working
way to resolve my problem, other than patching the kernel (e.g. your
beautifully crafted TS-driver) with the necessary non-linear adjustment
maths. It would be a temporary (famous last words) solution, so I can
work on other missing things on this device.
root@NesoLT:~ set
[...]
TSLIB_CONSOLEDEVICE='none'
TSLIB_FBDEVICE='/dev/fb0'
TSLIB_TSDEVICE='/dev/input/event0'
[...]
So, I guess you are using a different touchscreen library. Maybe you
should
take a look into our PTXdist [1]. Refer the "rules/tslib.make" file
for the
selected tslib revision and "patches/tslib-1.0/" for additional
patches to
make it work.
[1] http://www.pengutronix.de/software/ptxdist/index_en.html
http://www.pengutronix.de/software/ptxdist/download/ptxdist-2012.02.0.tar.bz2
Heh, I was wondering about a possible switch from the current
openembedded distro to ptxdist, given the excellent community support.
My initial attempts (30 minutes) of trying to even get one simple tool
compiled using the ptxdist git tree failed on my inability to find the
projects folder/tree/package (I managed to get my name configured :)).
Unless I find this, I suspect I won't be able to even generate a
toolchain with ptxdist, if I can't set up a project. It also seems that
I can't use the pre-built arm-toolchain provided by a simple 'sudo
apt-get install gcc-arm-linux-gnueabi g++-arm-linux-gnueabi
cpp-arm-linux-gnueabi' on any current ubuntu distribution.
I have yet to see it working. It's been compiled from openembedded,
just like all the other tools that work on this device. Do you
happen to
have a working tslib.ipkg (armv5te) around somewhere for me to test?
@Dave: please help me to explain, why it is no real solution to
exchange
binaries from different distributions in the hope they can work
together. ;)
I can provide an ipkg, because PTXdist creates this kind of package
from each
package it builds. Please do not complain if it does not work in your
root
filesystem (sent offline).
I will at a later stage, because my EC2-based build just worked.
Cheers
--
Joan C. Abelaira
