-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: > On Mon, Mar 10, 2008 at 07:22:54PM +0000, Andy Green wrote: >> It seems the place where the slow clock rate is defined for landscape is >> outside of the kernel? Where is this actually selected? > IIRC, it is set by Xglamo on rotation.
Ah I see, thanks for the explanation. Well I will force it in the kernel for testing I guess. >> I tried to use fbset but it just seems to trash the stride of the >> display somehow... has this ever worked? >> Eg, >> # fbset -g 480 640 480 640 16 >> should be a "no-op" when done on the default text framebuffer, but it >> trashes the stride. > It is a no-op on my GTA02v5 when in the console (X not running) or X is > in portrait mode. I run the daily build from last Friday. Hum me too now (I must say the rootfs has come on quite a bit since the old one I have been using for ages... makes sounds and everything... encouraging). > It trashes the stride when X is in landscape mode. It is an expected > behavior since the kernel doesn't(?) notify Xglamo about geometry > change. OK. It makes a bit of sense now that there is no rotation option in fbset then, this is happening on the X layer above. I will try to force the landscape to use 24.5MHz in the kernel with correct settings for HSYNC and so on and see what happens. Currently I forced the pixel clock to be the same 40ns in the kernel regardless of how it was set, and I see the artifacts you mentioned. Right now in addition it seems each line is repeated because I only see the top half of the video... I guess this is due to my messing up its calculations by forcing the pixel clock somehow. PCLK: 24.5MHz VSYNC: 42Hz HSYNC: 26.8kHz HSYNC / PCLK period --> ~930 pixels/line <==== !!! VSYNC / HSYNC = 643 lines / frame But the most interesting thing is that like this redraws from the CPU to the video become incredibly slow, updating a digit on the clock takes a seconds or so and is visible. Clearly we are starving the CPU from accessing the glamo RAM because we are maxing out the bandwidth to the glamo RAM. Maybe this can be the reason for the twinkling. Either way this is interesting news, at 930x643 24.5MHz frames CPU side access to the Glamo memory appears to be pretty badly starved in arbitration. But the pixel clock rate is the same, just longer lines. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH1liYOjLpvpq7dMoRAumrAJ9B0a+oMpTQzcgA5+XkrKrpFFKGhACgiBX0 732G2FPo7k3SxwPDURmWpdQ= =grbm -----END PGP SIGNATURE-----
