Hi Jürgen
This is a follow-up:
We've had a huge amount of success in the touchscreen department, and
also with the backlight functionality.
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:
Now it works, with the following section added and the according xorg
libraries recompiled:
Section "InputDevice"
Identifier "touchscreen"
Driver "tslib"
Option "CorePointer" "true"
Option "SendCoreEvents" "true"
Option "Device" "/dev/input/event0"
Option "Protocol" "Auto"
EndSection
What's working so far
---------------------
+ your driver works quite fine both in 2.6.x and 3.3-rcX kernel
series
Scratch that, your driver now works excellent, even without the in_sync
option. It's almost pixel perfect, thanks to a few changes in the PCB
(15nF capacitors).
+ 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.
This is fixed now.
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.
The new hardware design for the cable connector includes 4 layers now
and a cleaner design. The prototypes I have made showed promising
results.
+ 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)
Funny enough, with the 10nF capacitors the t_settling time in your
patch matches exactly our calculations plus a 100% safety margin:
t-settling = (xr_ohm + yr_ohm + r_opt + r_par) * (c_opt + c_par) * N *
ln 2
xr_ohm: 793, yr_ohm: 400, r_opt:0, r_par:10, c_opt:10nF,
c_par:15pF, N:12 bits
t-settling(chunghwa) = 100us -> safety margin: 2 x 100us =
200us
Now, another thing was the PWM driven backlight. I believe I have found
an elegant solution to hook up the PWM4 without daisy-chaining the PWM1
(which is in any case not according to the data sheet specification), as
done in your patch. I am talking about your following change, which I
still disagree, violently if I may say so :):
-#define MX25_PAD_PWM__PWM IOMUX_PAD(0x314, 0x11c, 0x10,
0, 0, NO_PAD_CTRL)
+#define MX25_PAD_PWM__PWM IOMUX_PAD(0x314, 0x11c, 0x10,
0x508, 1, NO_PAD_CTRL)
Now, in our case we've used GPIO_1_26 for led, which in any case would
have impeded us to use PWM1 for the backlight control. However,
according to the i.MX25 reference manual, page 2152, only ALT6 is used
in daisy chain (consistent with the current kernel setting), and ALT0
(PWM_PWM) is not.
You might use the CONTRAST_CONTRAST in input setting 0x14, which
corresponds to MX25_PAD_CONTRAST__PWM4_PWMO; a setup with worked very
fine for us.
These are the relevant sections to take care of (well, you know what I
mean):
#define BACKLIGHT_PWM_ID 3 /* Set to PWM4 for pin:
MX25_PAD_CONTRAST__PWM4_PWMO */
static int noah_init_backlight_pwm(struct device *d)
{
struct platform_device *pdev;
printk("%s: enabling PWM0 for backlight\n", __func__);
pdev = imx25_add_mxc_pwm(BACKLIGHT_PWM_ID);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
return 0;
}
Now, your patch put brightness values between 0 and 4095, which cannot
be according to drivers/video/imxfb.c:imxfb_bl_update_status():
static int imxfb_bl_update_status(struct backlight_device *bl)
{
struct imxfb_info *fbi = bl_get_data(bl);
int brightness = bl->props.brightness;
if (bl->props.power != FB_BLANK_UNBLANK)
brightness = 0;
if (bl->props.fb_blank != FB_BLANK_UNBLANK)
brightness = 0;
pr_debug("%s called with '%d'\n", __func__, brightness);
fbi->pwmr = (fbi->pwmr & ~0xFF) | brightness;
^^
Using 4095 you overwrite bits of
pwmr
[...]
Hence, the following adjustments to your backlight implementation:
static struct platform_pwm_backlight_data noah_backlight_info = {
.pwm_id = BACKLIGHT_PWM_ID,
.max_brightness = 0xff,
.lth_brightness = 0,
.dft_brightness = 0xff,
/* Chunghwa LED driver, with PWM frequency of 20 kHz */
.pwm_period_ns = 50000, /* 50 us -> 20 kHz */
.init = noah_init_backlight_pwm,
};
With these changes, we can fully operate the LCD brightness using
sys-fs in 256 intervals and observe a linear change of ratio in the
signal division of the PWM4 in the oscilloscope.
Thank you for sharing your NESO work, it helped a lot in understanding
all LCD related functionality and the kernel relevant parts of code.
With best regards
--
Joan C. Abelaira
