BeagleBox: Stripping themes, new bugdb project, updated Design
[Print This] By mjhammel ~ August 29th, 2010. Filed under: BeagleBox, Hardware, Linux, Software Development.
I’ve updated the Design page to reflect the knowledge I’ve acquired about the OMAP SGX and DSP. There’s still some work to be done in understanding exactly how Clutter fits into that picture but I’ll get there eventually.
In the meantime I’ve completed stripping out the theme support from the window manager. What’s left is the standalone theme which is very basic window decorations. I’ve also made Xft required, which in turn makes Freetype required. It seems plausible to me that future requirements for the window manager may include some OSD so keeping Xft seems a wise idea for the time being.
But the goal of stripping themes is to remove all window decorations. A set top box doesn’t need them. So eventually the standalone theme has to be removed to, or at least removed from top level windows. We still need some form of window decoration for transient windows that pop up – something that separates them from the background of the main window. And we need the option to move them around the screen. Think about what you would want to do with a Picture-in-Picture window. The window remains open for a time but you may want to move it to the upper right corner or lower left corner of the display. Users should have that option, and that means transient windows need to have window decorations that allow that kind of interaction.
I’ve checked in the updated window manager changes that stripped most of the theme support. While doing this I realized it made sense to track BUI progress separate from BeagleBox so I created a new project in Flyspray for BUI and moved existing tasks related to BUI out of the BeagleBox project and into the new project. I also created a set of tasks that I know need to be done for BUI. Staying organized is important in projects like this. At least it is to me. Every now and then you gotta go back through your resources and clean them up and make sure they reflect the current state of the project.
Related posts
BeagleBox: Adjusting the design, learning about SGX and DSP
[Print This] By mjhammel ~ August 26th, 2010. Filed under: BeagleBox, Hardware, Linux, Software Development.
I’m working two main issues at the moment: stripping Matchbox to get a new BUI core and working on building and packaging the SGX SDK drivers. The former is going well. I’ve stripped session management and gconf already and checked those in. I’ve got themes stripped down so that the build is just what it would be if STANDALONE were used with configure. However, I still need to properly strip the standalone configure options and verify that before checking in the changes. In my developer tree the build is now a minimal window manager with only simplified window decorations. The goal here is to strip the window manager down to a minimalist environment before trying to add pieces back in and start work on the panel.
The SGX SDK drivers are a bit of a different story. There is a lot of information available from the TI and eLinux.org wikis about how to work with this. And while it’s all fairly well written I found it difficult to determine exactly which kernel to use as a baseline. The release notes for the -07 release say that the AM35x/OMAP25x PSP (version -06) should be used. The PSP is the Platform Support Package and includes a patched version of the kernel along with a collection of the patches applied to the kernel source (along with other things like a prebuilt u-boot image and root filesystem). The kernel source is the 2.6.32 kernel from the tmlind git tree with a specific git id. The instructions say to use the omap3_evm_defconfig target, but for the BeagleBoard it seems more appropriate to use the omap3_beagle_defconfig target.
If we pull the proper git source we still need to apply the patches. To get these you have to unpack the SGX SDK, then unpack the kernel source packages. Only then can you apply the patches to the tree (assuming you don’t use the kernel source that is already patched in the SGX SDK).
I’ve updated the build in my developer sandbox to test this and it works okay though none of it is tested on the board yet (still don’t have one – mid-September for that purchase). I still need to add support for unpacking the patches. By not relying on the patched kernel source in the SGX SDK we can keep aware of how these pieces are being pulled together. Remember, this project is also a learning process.
From SGX to DSP
While doing all that work on the SGX SDK to merge it into the build I downloaded and read Introduction to creating 3D UI with BeagleBoard, a paper on that describes the SGX SDK and how to use it with the BeagleBoard. Something it also describes is the C64+ DSP. This is the component of the OMAP processor responsible for hardware accelerated video playback. This was interesting to read since, while I’d heard about the DSP, I wasn’t aware of it’s association with video playback.
What this means is that the SGX support will provide us some OpenGL support for use with gnash, which provides our flash player along with providing us some options for eye candy in the UI. But other video playback, such as H.264, will be through the DSP. Without the DSP we can still play video but only through the processor itself using software decoding. That potentially limits the size and quality of the videos we’d be able to play.
So I have to integrate the DSP support into the build too. Along with drivers there is a user space component based on the gstreamer infrastructure. Those will also have to be integrated.
And that meant I had to revisit the software stack in the BeagleBox Design. I’ve rebuilt the image depicting the stack. But I still need to update the Design page to reflect the changes. And then determine what that means to the Architecture. But at least I now have a much better idea of what I need to integrate from off-the-shelf components and what those components should provide.
Related posts
BeagleBox: kernel update, BUI initial release and analysis progress
[Print This] By mjhammel ~ August 19th, 2010. Filed under: BeagleBox, General, Hardware, Linux, Software Development.
I’m in the process of doing an analysis of the Matchbox code to determine what needs to change in it to create BUI. So far I’ve mapped out the basic code flow and identified the purposes of the files within the window manager, which is where I’m starting the analysis. Yesterday I experimented (lightly) with some changes to see if I could identify where the wm resized clients when the panel opened and closed. I found it in dockbar_client.c:dockbar_client_show() which calls wm_update_layout(). While this code is associated with that resizing, just commenting out portions of it is not sufficient. If I do that, the client gets resized too large. So this is just the start of changing that resize handling process.
I also made a release of BUI 0.1 yesterday on SourceForge. That’s just the original Matchbox code in a build environment. It includes a target for testing the code under Xephyr too. No changes to Matchbox yet, however. It’s just a starting point for anyone interested in diving into this with me.
While working on the Matchbox analysis I ran the BeagleBox build for the beagleboard hardware. This differs from the qemu build in that the Cortex-A8 compiler is built instead of the A7 compiler. In doing this I found a number of problems with that part of the build. First, the A8 compiler was not getting built the way I thought it would. I have to keep separate config files in the BeagleBox source tree specific to how I want to build the compiler due to the way I’m building it (not because of any kind of limitations in Crosstool-NG – the issue is in how I’m building the BeagleBox tree). Once that was fixed I updated the kernel build to the latest kernel being built by OE’s OMAP builds, which is kernel 2.6.32 from the tmlind git repository. Then I migrated in the xterm and surf updates to the buildroot. So now the beagleboard build should be up to date as much as possible. I can’t test it yet since I don’t have a BeagleBoard. I expect to make that purchase in mid/late September. Note that Crosstool-NG recently rev’d their release. I have not rev’d my build to use the new release. I’ll look at that later (added a Flyspray entry to cover it).
In the mean time I continue work on BUI and integration of the SGX components to the BeagleBoard build. Anyone interested in joining in should take a look at the Flyspray list of tasks to see what you might be interested in working on.
Related posts
BeaglBox: BeagleBox UI (BUI) initialized in CVS
[Print This] By mjhammel ~ August 14th, 2010. Filed under: BeagleBox, General, Hardware, Linux, Software Development, X11.
I decided a fork of Matchbox made the most sense for the BeagleBox UI. There isn’t much activity in Matchbox and the developers are busy with other projects. Besides, Matchbox is for hand helds while BeagleBox is an STB.
The fork is named BUI, for BeagleBox UI. Not too original, but simple enough to remember and type.
I ported over the Matchbox components I need for BUI into a build tree and checked it into the bui module in CVS. Now it’s ready to be worked on to evolve it into the BUI environment.
Related posts
BeagleBox: Matchbox metabuild to generate patches for buildroot
[Print This] By mjhammel ~ August 11th, 2010. Filed under: BeagleBox, General, Hardware, Linux, Software Development, X11.
I signed up for the Matchbox mailing list last night and have just sent a request to find out the status of the project. While I was waiting for confirmation of my sign-up last night I started a metabuild for Matchbox. Essentially its just like the metabuild used by BeagleBox, but this is just for Matchbox and it doesn’t cross compile. The intent is to create a work environment where Matchbox mods can be tested under Xephyer on my development systems. Eventually I’ll automate the build so that when I’m ready to create patches that can be migrated to BeagleBox I’ll have the metabuild do that for me..
So far I just have the lib and desktop in the metabuild but the process works well so I should have the rest configured later today (or tonight after work).
Related posts
BeagleBox: Matchbox revision issues
[Print This] By mjhammel ~ August 10th, 2010. Filed under: BeagleBox, General, Hardware, Linux, Software Development, X11.
The version of Matchbox’s panel and desktop programs in buildroot are pre-1.0. The latest available from Matchbox’s site are 2.0. I tried to patch buildroot so that the 2.0 panel would build. This required disabling dbus during the configure and patching the applets/Makefile.in to prevent the notify applet from building. That applet requires dbus and the build doesn’t work without special handling (which I hadn’t been able to figure out yet) to use the dbus installed by buildroot in the target directories.
Once I got the 2.0 panel built I launched it under QEMU, along with the updated 2.0 desktop. The desktop turned out to be a big app under the xterm window I also launch at startup. And the panel didn’t seem to show up anywhere or maybe was there but I didn’t see it cuz it was offscreen or something. So there is some work to be done to get the 2.0 apps working under buildroot for BeagleBox.
Switching back to the 0.9 series for Matchbox apps I tested that the orientation setting for the panel works. It does. So the question is now whether to apply patches to panel 0.9.3 or try to update to 2.0. I looked at openembedded and they’re still using the 0.9.3 version of the panel as well. I noticed some older posts about Matchbox-panel-2 (via google) but it isn’t clear if those are the ones that should be worked on.
Matchbox doesn’t appear to have much active development so I’m wondering if I should fork it and build my own desktop/window manager tools for BeagleBox that are based on the 0.9 series of Matchbox. The nice thing about that is that the code is relatively easy to follow and fairly simplistic. It’s like starting with a window manager template. I wouldn’t want to tick off the Matchbox folks, of course. I should probably check with them on the status of that project.
Related posts
BeagleBox: XComposite enabled under QEMU
[Print This] By mjhammel ~ August 8th, 2010. Filed under: BeagleBox, General, Hardware, Linux, Software Development, X11.
I spent the weekend trying to figure out why I couldn’t get the XComposite extension to show up under the fbdev X driver under QEMU. It took until Sunday night to figure out that I need the cirrus fbdev kernel driver along with turning on xdpyinfo, libXcomposite, and the Cirrus X driver in buildroot. I added xcompmgr as a package to buildroot too, to see what what would happen if I ran it under Matchbox and QEMU. Turns out nothing happens. At least not yet. But now I have a QEMU configuration that will allow me to experiment with Matchbox’s menus to get alpha blending working.
All this because I can’t afford the BeagleBoard yet. The more I can get done under QEMU the better. I’m dying to get my hands on the hardware, but that will have to wait for about a month. The cars need tires this month.
I also tried to build OpenBox to see if it might be a better alternative to Matchbox. But it didn’t want to compile without a lot of work. I don’t know why, but I think I prefer Matchbox’s simplicity. I’d rather extend Matchbox than patch OpenBox to get what I need working. I’m sure OpenBox is a fine window manager. But starting simple has always been a modus operandi for me.
Related posts
Bug db migrated from SourceForge to Muse site
[Print This] By mjhammel ~ August 5th, 2010. Filed under: BeagleBox, General, Hardware, Linux, Software Development.
I didn’t like the content and management features of SourceForge’s bug tracker so I’ve migrated all the BeagleBox issues from there to a Flyspray-based bug tracker running on my site. Flyspray provides finer grain organization of issues and allows a visual display-at-a-glance of the status (how much work is done) on the issue. We use this at work quite heavily and are very pleased with it. I’ve not used it in the open like this previously so I’ll have to see how well it holds up against the meanies in the field.
Having used Bugzilla, DDTS, and a slew of other issues trackers, I find Flyspray to be far easier to manage while providing much greater flexibility in use. While it lacks extensive reporting capabilities, that’s something I’m sure the developers could add with a little support and encouragement from the community.
Related posts
BeagleBox update: Matchbox is now the default UI, surf browser added to build.
[Print This] By mjhammel ~ August 5th, 2010. Filed under: General.
The build for the QEMU phase now runs Matchbox as the default UI. I’ve integrated an xterm patch from Buildroot’s source tree and launch it as the default application, allowing some runtime testing through the UI.
Today I also finished integration of the surf browser into the buld. This was done by creating a new buildroot package for surf and patching surf code to work within the bounds of buildroot’s versions of GTK+ and WebKit. Essentially, this means a minor patch to backport newer features of GTK+ Adjustments that were being used in surf and to disable surf’s ability to view source from a web site which is not supported in the version of WebKit that is in the stable buildroot release.
Just for fun I loaded google.com, my web site and thedailyshow.com under qemu. As expected, google.com worked fine but the other two were quite taxing to QEMU. I certainly expect better performance when testing on the BeagleBoard.
With these changes I think I’m getting close to ordering my BeagleBoard. I have enough of the system coming up in the UI to make it worth experimenting with its performance on the board when connected to a TV. I’ll probably need some additional mods to the build to support the board completely, such as a proper kernel with BeagleBoard HW support which may or may not come from OpenEmbedded. I may need to keep to copies of the build tree, one for testing UI components under QEMU and one for testing on the board. This is because the former will use one version of the crosstools while the other will use a different version that is more hardware specific.
Related posts
Announcing BeagleBox: Internet video platform for the BeagleBoard
[Print This] By mjhammel ~ August 1st, 2010. Filed under: BeagleBox, General, Hardware, Linux, Software Development, X11.
I’ve gotten the embedded bug lately. I dug around for an interesting hardware platform to work with and stumbled across the BeagleBoard. This 3×3″ board provides impressive multimedia capabilities via the TI OMAP35xx processor. It appears to serve the purpose I had long ago thought about for the miniITX boards – a media platform. miniITX is still useful for this, but this little board is even better suited to the task. But there are a lot fo things to be done to get it going.
So I’ve started a new project which I call BeagleBox. The goal is to build a device that can play Internet video based on user selections, allowing users to be free of ISP-driven control of the online video experience. Initially the project is targeted at running under QEMU to build the UI components without real media support. Once the core UI is ready the project will migrate to the hardware.
I’ve setup a SourceForge site and a wiki under my muse site. I’ve got a metabuild system ready that will bring up a kernel and file system running X and a basic blackbox window manager. The wiki lays out the plans for this project. I’m currently working to bring up Matchbox instead of blackbox because Matchbox, possibly (likely) a modified version, will server as the core UI. Eventually MythTV and surf will be added to provide media support.
Feel free to comment on what you think of this project, including where you think it should lead and/or include.
Loading ...
