One of my goals for the zipit is to get gtk running on Directfb so I can have all sorts of goodies built outta gtk; like fbreader, some OpenStreetmap stuff, and even xdialog. The Directfb folks have a recipe with about 100 steps to do this, but I'm not so good at following directions, so I haven't got it done yet. I did manage to compile all the various bits and pieces, supposedly in the right order too. But all the gtk programs I've tried (even the tiniest of demos) crash when I try to run 'em. Prolly something's not configured right in one of the many layers leading up to gtk. So I decided to start testing things from the bottom layer up.
The first new layer in the gtk food-chain is Directfb. Now iz2s comes with a Directfb of sorts. It provides the g for the graphical links browser. But it has a few warts, sorta like the iz2s alsa libs. Once again the libs are compiled to look for things in a weird, nonexistent path. The iz2s glinks works around this by explicitly linking with the fbdev and keyboard modules in their unusual location instead of allowing the main Directfb lib to load them on demand from the normal places. That's fine for glinks, but it interferes with my plans to build more stuff on directfb. Now apparently each consecutive version of iz2s has a different build of glinks. And fortunately it turns out one of 'em was compiled with the normal lib setup. But it had issues with the keyboard. Oh well. Also, I discovered the hack used to rotate the glinks display is really just a window rotate, and not a screen rotate, so the mouse does not reorient itself as well to match the display. Once again, fine for glinks running mouseless, but not so good for me and my nefarious plans.
Then it hit me. I've already spent a considerable amount of time patching up SDL to solve various screen, keyboard, and sound issues. And Directfb can be built to run layered on top of SDL in addition to running directly on fbdev. Maybe I can fix both layers with one set of patches. So I rebuilt Directfb with both backends enabled and tried it. The SDL backend fixed the keyboard issue, the mouse rotation problem, and even the blinking cursor bug. Whoo Hoo! It doesn't support double buffer mode, but neither does the the fbdev backend, unless you run it without the 90 degree CCW rotation required to match the screen orientation with the keyboard.
I'll probably have to patch SDL yet again to add the rotated double buffering. The SDL screen rotation code uses what they call a "shadow" buffer to hold the pre-rotated pixels. So it's already double buffered. The only difference is the timing of the updates. The shadow implementation sneaks in the updates when you're not looking, whereas regular double buffering does it on page flips. I honestly don't know how the SDL folks missed that.
Meanwhile I think I might just try to build fbvnc so I got something useful to show for all this work, not just a bunch of demos and an irrelevant mouse pointer for glinks. And maybe I'll even do a little sidetracking and build FLTK_Directfb and then murga-lua, just in case I never make all the way up past gtk to the xdialog layer. Otherwise, next up is the glib layer. I gotta find me an interesting program that'll put glib through its paces without requiring a full up gtk install...
No comments:
Post a Comment