Fwd: LCM flicker

Wolfgang Spraul wolfgang at openmoko.com
Sun Mar 9 12:21:27 CET 2008


fyi

Begin forwarded message:

> From: Andy Green <andy at openmoko.com>
> Date: March 9, 2008 5:38:30 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:
>> On Sun, 9 Mar 2008 16:15:10 +0800 Wolfgang Spraul <wolfgang at openmoko.com 
>> >
>> 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.
>
> 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.
>
> - -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-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080309/744fa07f/attachment.htm 


More information about the openmoko-kernel mailing list