Lately the nice folks on the zipit IRC channel have been full of useful rockbox tidbits, so I took a short break from the framebuffer goodies to do some more work on the rockbox goodies. For the latest, check the Zipit goodie bag link on the right.
For starters, I finally built a t11 build for z2lite with the newer code from March so it matches the latest IZ2S build. I also found out on IRC that plugins built for z2lite (eabi) are somehow compatible with iz2s (oabi). So I updated the plugins to fix some keyboard issues with bubbles and rockblox, and made new plugin packages that apparently run on either userland. From now on I'll make a separate zip for the plugins.
However dronz on IRC discovered the r20 rockbox builds from the January rockbox code have better high frequency sound than the t11 builds from the March code. It'll take some time to track down and fix this so it may be a while before I get back to the vnc and framebuffer stuff. Feel free to express your disappointment in the comments section. ;^)
Fun with software, gizmos, virtual bricks, and other geeky toys.
Saturday, May 28, 2011
Friday, May 13, 2011
VNCx3
So it turns out there are at least three framebuffer vnc clients out there that might be useful in the IZ2S userland on the zipit. There's the old ipaq/zaurus fbvnc that looks like a good fit for the tiny zipit screen.
There's a nice simple fbvnc here along with some other minimal fb programs.
And finally there is directvnc which runs on top of DirectFB instead of directly on /dev/fb0.
Naturally none of them really fit my needs. The ipaq/zaurus fbvnc looks the most promising because it's got scaling, panning, and rotating already built in for use with small screens. But the code is old and needs updating to make the keyboard and mouse work. Also the nifty screen rotation goes the wrong way, so I can have the screen sideways, or upside down relative to the keyboard. I borrowed the mouse code from the litcave fbvnc so at least that works now. Panning also works. I hooked in the battery monitoring code from rockbox, connected the backlight dimmer to some of the many variations of kbd led controls in IZ2S, and attempted to hook the volume control to alsamixer. So if you don't mind working sideways with an onscreen keyboard instead of the real one, then you might be ok with this fbvnc as is.
I suspect the keyboard will only take a small fix like the mouse, but the rotation is gonna be a challenge. The rotation code is a bit of a mess with multiple unnecessary conversions back and forth between the local and remote coordinate systems, and massive hand unrolled loops to optimize the code at the point where it actually needs to draw the pixels.
The litcave fbvnc is no frills, and either uclibc doesn't like some socket call it makes, or else it's lack of password support is blocking me. Either way, it's probably only useful to me as a source for the simpler mouse/keyboard code.
Directvnc connects and puts up a screen, rotated correctly by leveraging my previous work with DirectFB and SDL, but the mouse fails to move. And the only keys I've verified are the Ctrl-Q key combo to quit. I can probably borrow some working mouse code but once again the lack of panning or scaling makes this fairly useless on the zipit.
What I really need is the keyboard/mouse code from the litcave fbnc, the correctly rotated DirectFB screen from directvnc, and the rest of the goodies from the ipaq/zaurus fbvnc. I may just end up with that eventually.
There's a nice simple fbvnc here along with some other minimal fb programs.
And finally there is directvnc which runs on top of DirectFB instead of directly on /dev/fb0.
Naturally none of them really fit my needs. The ipaq/zaurus fbvnc looks the most promising because it's got scaling, panning, and rotating already built in for use with small screens. But the code is old and needs updating to make the keyboard and mouse work. Also the nifty screen rotation goes the wrong way, so I can have the screen sideways, or upside down relative to the keyboard. I borrowed the mouse code from the litcave fbvnc so at least that works now. Panning also works. I hooked in the battery monitoring code from rockbox, connected the backlight dimmer to some of the many variations of kbd led controls in IZ2S, and attempted to hook the volume control to alsamixer. So if you don't mind working sideways with an onscreen keyboard instead of the real one, then you might be ok with this fbvnc as is.
I suspect the keyboard will only take a small fix like the mouse, but the rotation is gonna be a challenge. The rotation code is a bit of a mess with multiple unnecessary conversions back and forth between the local and remote coordinate systems, and massive hand unrolled loops to optimize the code at the point where it actually needs to draw the pixels.
The litcave fbvnc is no frills, and either uclibc doesn't like some socket call it makes, or else it's lack of password support is blocking me. Either way, it's probably only useful to me as a source for the simpler mouse/keyboard code.
Directvnc connects and puts up a screen, rotated correctly by leveraging my previous work with DirectFB and SDL, but the mouse fails to move. And the only keys I've verified are the Ctrl-Q key combo to quit. I can probably borrow some working mouse code but once again the lack of panning or scaling makes this fairly useless on the zipit.
What I really need is the keyboard/mouse code from the litcave fbnc, the correctly rotated DirectFB screen from directvnc, and the rest of the goodies from the ipaq/zaurus fbvnc. I may just end up with that eventually.
Wednesday, May 4, 2011
Layers upon Layers.
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...
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...
Subscribe to:
Posts (Atom)