fyi
Begin forwarded message:
From: Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
Date: March 9, 2008 6:17:56 PM GMT+08:00
To: Andy Green <[EMAIL PROTECTED]>
Cc: Wolfgang Spraul <[EMAIL PROTECTED]>, Sean Moss-Pultz <[EMAIL PROTECTED]
>, William Lai <[EMAIL PROTECTED]>, "Tony Tu)" <[EMAIL PROTECTED]>,
matt_hsu <[EMAIL PROTECTED]>, Chia-I Wu <[EMAIL PROTECTED]>,
Werner Almesberger <[EMAIL PROTECTED]>
Subject: Re: LCM flicker
On Sun, 09 Mar 2008 09:38:30 +0000 Andy Green <[EMAIL PROTECTED]>
babbled:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Somebody in the thread at some point said:
On Sun, 9 Mar 2008 16:15:10 +0800 Wolfgang Spraul <[EMAIL PROTECTED]
>
babbled:
raster -
again, landscape is off right now, we can disable landscape
altogether
for now. If you think this can later be fixed in software by
using the
2d engine to do in-lace, EVEN BETTER!
that's what i said. if u want landscape - u get flicker. too bad.
we can
disable it in software. i did not advocate that we sink time into
fixing it
now. we CAN fix it later. we have an opt-out clause.
But right now let's focus on the portrait flickering.
Your observations are great! Real news...
well that's just what i noticed. it could also be our 50hz
refresh. thats
what xrandr says we are doing, and 25hz in landscape mode. that is
the
killer. the lcm is probably expecting 60hz minimum.
Hi Carsten --
Interesting about the different colour channels acting
differently. If
it is easy for you, maybe you could also try alternate red/blue
lines on
a stride of 2 or 4 for example to see if there is a pathological
pattern. When we had this bug with the PLL divider register getting
trashed on the Glamo and we saw really slow refresh (like ~1Hz), I
noticed there seemed to be some kind of interlace action going on
where
the redraw was happening. It didn't look like true progressive scan.
If you do the math on the PCLK vs actual overscan effective pixels,
it
comes out to 60Hz is what we deliver in portrait right now.
There's no
way 60Hz noninterlaced refresh should give flicker by itself.
hhmmm. then xrandr is lying to me, it claims 50hz. aqnd it claims
25hz for
landscape mode (which explains the much worse flicker).
Either the refresh action we perform "beats" against another
oscialltor
inside the LCM ("booster" or this "internal" osciallator), or there
is
some kind of PWM trickery used to get the intensity levels that we
beat
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.
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFH07AWOjLpvpq7dMoRAiUlAJ9KoQLqsX8hW+IPHwwzU0DfGTRwZgCfRV1Y
SarAlpZB/cZdMbTe4HfvSzQ=
=ecwK
-----END PGP SIGNATURE-----
--
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
