Fwd: LCM flicker
wolfgang at openmoko.com
Sun Mar 9 12:21:43 CET 2008
Begin forwarded message:
> From: Andy Green <andy at openmoko.com>
> Date: March 9, 2008 6:50:31 PM GMT+08:00
> To: "Carsten Haitzler (The Rasterman)" <raster at openmoko.org>
> Cc: Wolfgang Spraul <wolfgang at openmoko.com>, Sean Moss-Pultz <sean at openmoko.com
> >, William Lai <will at openmoko.com>, "Tony Tu)" <tony at openmoko.com>,
> matt_hsu <matt_hsu at openmoko.org>, Chia-I Wu <olv at openmoko.com>,
> Werner Almesberger <werner at openmoko.org>
> Subject: Re: LCM flicker
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Somebody in the thread at some point said:
>>> hhmmm. then xrandr is lying to me, it claims 50hz. aqnd it claims
>>> 25hz for
>>> landscape mode (which explains the much worse flicker).
> It is true that landscape is 1/2 the rate of portrait currently, but
> x 600 (the overscanned y and x) at 24.5MHz PCLK (41ns period) comes
> to 16.6ms == 60Hz.
>> Either the refresh action we perform "beats" against another
>> inside the LCM ("booster" or this "internal" osciallator), or there
>> some kind of PWM trickery used to get the intensity levels that we
>> against somehow.
>>> i haven't found a pathological pattern yet - but it seems a smooth
>>> gradient - in
>>> ANY direction seems to bring it out. that doesn't help me figure
>>> out what kind
>>> of pathological pattern is causing it. for that matter a solid
>>> orange color
>>> region flickers too - all by itself. no gradient needed.
>>> rgb: 255 145 0 does a wonder flickering job. this is totally
>>> bizarre unles u
>>> look at there being some temporal interference pattern on the r &
>>> b signals
>>> that doesn't affect g, and the interference pattern is inverted
>>> between r & b.
> Hum well it is a big clue for sure since we can make the problem come
> and go depending on colour. I guess the first question we should
> ask is
> can the glamo being doing it really early in the actual pixel data
> by frame. I will try to fill the display with this colour and have
> a look.
> Another thing I noticed is that we have an insane RC filter on PCLK
> currently, the signal quality on PCLK is pretty bad. But I can't
> make a
> story how that causes these outcomes.
> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openmoko-kernel