[PATCH] SMedia-Glamo-fb hardware cursor and fixes.

Andy Green andy at openmoko.com
Wed Jun 4 19:27:44 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Hey,
|   I played with the Glamo framebuffer and did some changes, see
| attachments and pick the changes you like.

Great.

| First patch (against recent -andy) fixes some Kconfig confusion,
| letting me build without GTA01 and KEXEC disabled.  At least one of
| the changes in this patch is correct ;)  The Kconfig dependency pieces
| for S3C24xx seem to be needlessly complicated and also broken.

Looks like it increased the sanity.

| The second file implements hardware cursor in the glamo-fb,
| unfortunately this doesn't mean that you can go and use it.  There had
| been some code for the hw cursor in the driver already but it was
| missing some important parts and other parts were wrong.  I fixed this
| and the cursor now looks very pretty, but now I see the Glamo blow up
| after a random amount of screen activity and the screen fades to
| white, while the rest of the system is unaffected.  Thus, the hw
| cursor code is still left #ifdef'ed out, it's just more correct now.

Wow screen fade to white must mean no pixel clock came any more, so when
it blew up, it blew up really well.

If you're ever interested to poke on it some more, the way forward would
be to dump the Glamo LCD regs before and after the "whiteout" so we can
see what is getting overwritten.  I had some nice code for that but I
seem to have mislaid the patch, I'll look a bit more for it.

| There's some misc clean-up too because glamo-fb.c is cluttered with
| lots of commented out and unused code.

Yes, thanks.

| In addition I allocate a FB type number in include/linux/fb.h for fb
| identification purposes once we implement scrolling/blitting/blending
| in hw (not meaning that I'm going to do this now ;)).  I see this
| functionality as optional and perhaps enabled with a second Kconfig
| option.  I would also like to see some form of malloc for the Glamo
| memory instead of hardcoding offsets like we do now.  IIRC Dodji's
| Xglamo implemented something like this.

Yes I can imagine it is good to deal with pixmaps and so on in offscreen
Glamo RAM.

| I'll keep playing with different "engines" of the graphics chip in my
| free time and see what I come up with.

Best of luck.  It's on "andy".

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkhG0JAACgkQOjLpvpq7dMqycACdG5qHbYt4VcLp3tsE7D+kAeZn
58AAn37y9MjqC+X+cjoUf6v7xLhQAbwX
=e9V8
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list