LCM flicker

Andy Green andy at openmoko.com
Mon Mar 10 13:00:38 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
> Hi All:
> 
>> I can already say the pixel data is DC when you fill the screen with the
>> single colour.  Specifically R0 and B0 from the glamo are also DC for
>> the entire frame :-/  There is nothing to diff interframe, it's DC.
>>
>> I'd like to blame the Glamo but it is making it hard to find a story
>> about why :-)
> 
> Yes, I agree. I also use the U-boot to find the lcm issue. 
> These color signals are always high or low, and they don't change. 
> If the color signal is not problem, theses VH,HS,DE, or CLOCK has problem.
> Therefore, I measure the VS and HS. 
> I found the VH,HS,DE, or CLOCK signals are all OK. 
> Please check theses JPG files are the GTA02's signal.
> Therefore, these signals are all fine, and maybe is the LCM panel problem.

Agreed -- apart from the clock quality is very bad after the 47pF but
apparently not to blame.  I have been meddling with the LCM ASIC
settings in U-Boot without any luck.  The problem there is we have very
poor information about the Toshiba JBT6K74 ASIC.  The "software design
guide" defines hundreds of register settings without any indication of
the meaning of the functions like "ASW" and "OEV".

I was able to turn off a few off these mystery features without
affecting the display action or the flicker.

I was on Toshiba's .jp site

http://tmd-product.tmdisplay.com/index_e.cfm

but of course there is nothing useful.

I like Joerg's idea that it is intentional dither somehow, but in the
LCM.  The reason is the flicker does not move around like "hum bars" on
a TV, where the second oscillator is unlocked to the video, and that is
strange when the redraw is raster-wise.  Also the perceived flicker
level changes when you tilt the display, but it is always a whole region
flicker.  So it suggests the bright and dim frames making up the flicker
are atomic frames locked to VSYNC.  The flicker is fast enough it can be
1/2 or 1/4 the frame rate of 60Hz.  We can see the Glamo does nothing to
make this because we see nothing like it on the signals to the LCM.  And
it reacts to the detail of the pixel colour LSBs, it does not seem like
a power rail problem.  So it makes us think that the LCM itself is doing it.

But there were reports that GTA01 with the same LCM does not create the
flicker.  Maybe this is because the GTA01 issued the video at a higher
frame rate and the flicker is less visible.  GTA01 and 02 share the same
LCM ASIC initialization code also.  Maybe the GTA01 batch of LCMs are
themselves different from the ones we currently use.

Maybe our next move should be to try 72Hz refresh by removing the
needless blanking pixels from the frame and keeping everything else the
same, if the LCM creates the flicker at some integer number of frames
then we will increase the flicker frequency accordingly, maybe it will
be less objectionable or transformed some other way.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFH1SLmOjLpvpq7dMoRAvE8AJ0eI0SYJW7mFE6aGvo/MOjqFrZXLQCfQY0T
9gpRDM6TZhEF7OP/Up3O/S4=
=77r0
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list