-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: > On Mon, 10 Mar 2008 08:27:23 +0000 Andy Green <[EMAIL PROTECTED]> babbled: > > Somebody in the thread at some point said: > >>>> one thing it could be is the LSB of all channels is wobbling, and since R & >>>> B have 1 less bit - it's much more noticable. green might flicker and we >>>> just > Good idea Carsten -- and in fact the physical interface to the LCM is > 6:6:6 fittingly enough, and that is what is wired through to the Glamo. > But glamo framebuffer in U-Boot anyway (X too?) is 5:6:5 and it is > *red* and *blue* that lack the LSB. > >> well 6bits is what the lcd accepts (6:6:6 indeed) and the glamo needs to fill >> in the extra 1 bit for R & G (G goes straight through as all 6 bits are >> used). >> that extra 1 bit needs to be interpolated from 0 to 1 as the other 5 bits >> increase in value. but flicker ONLY happens when R != B. and it gets worse >> the >> more difference between R & B. now if those lines are flapping and not >> grounded
Floating signals are generally a lot less controlled than this regular flicker though. We would see artifacts when someone turned on the lights or pulled out a plug in another room. The structure seems to be that the 5:6:5 goes through individual gamma tables in the Glamo and that is where the extra LSB is picked up. I'll start looking there. I looked at the Glamo LCD controller "Enable and Mode Setting Register 3" at +1104 and we are set for RGB 5:6:5 on the CPU side, RGB (not "LCD?") 6:6:6 on the LCD side and 18 bit if, so it is alright as far as that goes. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH1PpGOjLpvpq7dMoRAhhcAJ41k3oqVzplz9EQ5s13m4fcJdgq2ACePKD7 0HkVsQPLr0HLoMDqYRgQFLE= =Rhd8 -----END PGP SIGNATURE-----
