Hi Juergen
The most important and crucial step to fix
the jittering and weird Y value reporting was fixed by introducing 4
10nF
capacitors in parallel for the X+|X-|Y+|Y-, as indicated in the MX25
RM,
Figure 44-5, chapter 44.2.2. This significantly reduced the noise.
But you should keep in mind you must also extend the settling time if
you
increase the capacitive load on the lines. This will slow down
conversion.
The initial settling time of 200000 is just fine for us now.
The only problem we have left, is that we have no means of
calibrating the
pointer (still on X11 as the QT/E hasn't finished compiling in
OpenEmbedded yet), so towards the right horizontal we can almost go
to the
limits of the touch screen, while towards the left horizontal, we
have
about 50 pixels that cannot be reached by the pointer. Any ideas
(ts_calibrate still does not work)?
"ts_calibrate" must work if the touchdriver reports reasonable values
via the
kernel's input subsystem. So, what exactly means "still does not
work"?
It just complains that it cannot find a valid touch screen device, as
always:
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"
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?
We have also found out why the 3.3-rc kernels introduced the washout
in
out LCD. Your hint with regard to the changes of the active state of
the
UPLL gave us the idea of fiddling with the LD[0-17], where we
pin-pointed
the problem down to LD16 and LD17. Through mere luck (as we don't
fully
understand the detailed implications of our actions) we made the
following
changes:
-#define MX25_PAD_GPIO_E__LD16 IOMUX_PAD(0x400, 0x204,
0x02, 0,
0, NO_PAD_CTRL)
+#define MX25_PAD_GPIO_E__LD16 IOMUX_PAD(0x400, 0x204,
0x02, 0,
0, PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_MAX | PAD_CTL_SRE_FAST)
-#define MX25_PAD_GPIO_F__LD17 IOMUX_PAD(0x400, 0x208,
0x02, 0,
0, NO_PAD_CTRL)
+#define MX25_PAD_GPIO_F__LD17 IOMUX_PAD(0x400, 0x208,
0x02, 0,
0, PAD_CTL_PUS_100K_DOWN | PAD_CTL_DSE_MAX | PAD_CTL_SRE_FAST)
"PAD_CTL_PUS_100K_DOWN" makes less sense for an output pin.
"PAD_CTL_SRE_FAST"
makes no sense, as this GPIO E group has no such bit to change (refer
table
513 in the datasheet).
I agree.
"PAD_CTL_DSE_MAX" makes sense if the electrical lines to your display
are very
long or the capacity load is high. But this setting will increase
power
consumption and also increases the EME. Keep it as low as possible to
fullfill your requirements. And: changing this value to get better
visible
results may shows the wrong clock edge is in use! Fill your
framebuffer with
static random data ("cat /dev/random > /dev/fb0"). If you see some
pixels
flickering you are using the wrong clock edge.
No flickering at all. It's working smooth as it should. I will however
reduce the bit fields to the PAD_CTL_DSE_MAX or less setting. Without
it, we have a massive wash-out effect.
This effectively not only fixes the washout, but it gave us much
better
color "saturation" and near pixel-perfect luminance.
If you need different settings for different LCD signals lines you
must check
your board layout. All these lines must be electrical equal!
I have been checking for a couple of days now, and there might be some
indication of noise introduced somewhere where it shouldn't be.
[...]
>> Another thing is that the Y position does not seem to be reported
>> correctly to the input system in our case, so we had to alter the
>> following line for "inverse" reporting
>> (arch/arm/plat-mxc/imx-ts.c:imx_create_event_for_4wire):
>>
>> - input_report_abs(ts->input, ABS_Y, y_pos);
>> + input_report_abs(ts->input, ABS_Y, 0xfff - y_pos);
>
> The same should work if you exchange the Y+ and Y- electrical
connectors.
Yeah, but considering that the connection is according to the data
sheets
Never trust a datasheet ;-)
Indeed, it's now working as is without the patch, the connections for
Y+|Y- were crossed.
Cheers
--
Joan C. Abelaira
FQ Ingeniería Electrónica, S.A.
Polígon Industrial Vilanoveta
Av. de les Roquetes, 9
E-08812 Sant Pere de Ribes (Barcelona)
SPAIN
Telf: +34 932 080 258
Fax: +34 934 592 893
Móvil: +34 638 331 745
http://www.fqingenieria.es/
email: [email protected]
