Michael J. Hammel – The Graphics Muse

My wife picked up a really interesting gift for me this holiday season.  It's a copy of the first book I can remember checking out of a library as a kid.  It's called Pat and the Iron Horse.  I don't actually remember the story that well.  It has something to do with the great Irish potato famine and a young man coming to America to work on the railroads.  I do remember enjoying it.  A little box filled with a whole different world.  And it was all mine.  Well, until I had to check it back in. 

But now I have my own copy.  To keep and cherish.  What's great about a gift like this is how it is more about who I am than what I want.  I love that she remembers what's important to me.  Books will always be very important to me.  Real books.  Not digital copies.

Related posts

• No related posts.

So I've upgraded three machines to F16 (from F14) so far, two at work and a laptop at home.  The latter I spent a lot of time tweaking to work as much like my old GNOME 2 setup.  XFce comes close but there are some tweaks an I have a few nitpicks.  These are my notes.

First:  make a list of all your GNOME panel-based applets and applications. 

I have a ton of menus in a panel across the top of my desktop.  I don't use the default menus much (except for an occasional use of the Applications menu).  Instead I organize my panel with a bunch of GNOME drawers, some with drawers within them.  There is no easy way to migrate these to XFce (that I know of, at least).  So I opened the properties for each applet and application icon and noted its menu position and command in  a text file.  When I got F16 up and running with a default XFce panel, I started adding these back in manually.  It's a bit of work if you have as many things in your panel as I do.  But it should only have to happen once, really.

xscreensaver can't be disabled in a session managed manner.  If you kill it, logout and login, it comes back on.  To solve that, I juse removed the package.

Firefox 8 doesn't work with my old theme (Vfox3-basic, a Mac-style theme).  I found a different Mac-based theme it's not as nice as Vfox3-basic.  Also, if you hover over a link it displays in the canvas, not in the status bar, making it difficult to read if there is text in the canvas at that spot.  Finally, the bookmarks toolbar font does not match the Firefox (re: system) font.  This is probably a theme issue.  All those Firefox updates are probably making it hard for theme authors to keep up (and Personas are useless).  To bad Chrome is just as bad.  Might be time to start exploring alternatives based on WebKit.

Worse problem encountered:  CPU fans constantly running in my laptop.  I Googled for this and ran into discussions about the compositor (3d effects) causing the problem.  However, those problems were with nVidia boards and the laptop has an Intel 915GM.  I turned the compositor off and didn't see much difference.  The problem was a bunch of "Tracker-*" tools that XFce started in its session configuration.  I disabled all of those and the CPU usage dropped dramatically.  CPU temps went from 179 F with the Tracker's on to 105F with them off.  Fans are also essentially silent now.

XFce has a bunch of extra utilities collectively called Goodies.  But these are not packaged together and are apparently not in the XFce group installed by the default XFce choice during F16 installation.  So you have to install them manually.  These include a bunch of panel bar applets.

• xfce4-cpugraph-plugin
• xfce4-datetime-plugin
• xfce4-genmon-plugin
• xfce4-netload-plugin
• xfce4-sensors-plugin
• xfce4-systemload-plugin
• xfce4-weather-plugin
• xfce4-wmdock-plugin

Some of the other minor nits I have with XFce:

• Panel menus don't inherit alpha of panel they live in and you can't configure them individually.  Window Manager Tweeks->Compositor "Pop Up Windows" applies alpha to menus but also to the icons in them so it's not useful for this purpose.
• The Launcher is actually used the same way as a GNOME drawer – providing a panel menu – but can't set the drawer icon without linking to an application or else you get an error if you click on it (however, you could use /bin/true as a workaround)
• Monitor applets (CPU, Network, etc) are thin bars instead of boxes.  Boxes are easier on my old eyes.
• DateTime plugin: two lines of text is annoying, no way to make it one line but it has a better Calendar than the other datetime plugins.
• xfapplet doesn't work with GNOME 3 (another reason to hate GNOME 3) and GNOME 2 applets aren't available anyway.
• Default double click on title bar for shade requires *very* fast click.  Settings->Mouse dialog: Behavior Double Click Time set to 310 seems to be a better setting.
• The Weather plugin doesn't seem to work.  It never updates ("No Data").

Worse thing that happened in the upgrade for the laptop:  The "d" key is flaking out on me.  It is a 7 year old laptop, but still.  That's the last time I clean the keyboard. 

Updates

2012-01-09

PulseAudio is not working properly and Alsa does not allow multiple applications to share audio output.  I was listening to an online music stream and tried to run Skype but the latter complained about audio problems.  The only way to get it to work was disable the online audio stream.  XFce does not have the PulseAudio configuration tool found under GNOME 2 so I could not select the application which would get the audio output.  Also, the only selection for output device in Skype that works is "HDA NVidia, ALC888 Analog".  Choosing "pulse(pulse)" doesn't work. 

X-Chat does not show up in the system tray (re: Notification Area).  No work around for that.  Bummer – I used to use the flashing system tray icon to notify me of incoming messages.

XFce's Workspace switcher bogs down badly.  I have two monitors using nVidia's driver for TwinView.  One workspace has a browser and evolution open.  Another workspace has 10-12 GNOME terminals plus a few other windows.  Moving from the former to the latter has a significant pause before changing, and the display update is very slow.  I'm not sure if this is a problem with the kernel, the nVidia driver or XFce's window manager or workspace switcher.

ssmtp has stopped working.  It's the same version as I was using with F14 and I've tried building it from source too.  Just refuses to work.  I've got suggestions to check the TCP packets to debug the problem as well as a suggestion to use msmtp instead.  Both are on my todo list.

Related posts

• Using Xine with your MythTV videos: small screens while you work (0)
• Multiple Firefox instances with different network settings (0)
• Intel graphics, xrandr and GNOME: the case of the moving panel (4)
• Fedora 10 and Firefox upgrade complaints (0)
• Dawning of a new age: A Quad-Core system finds a new home (0)

I’m playing with F16 at work, prep’ing for the big migration from F14.  I’ve already installed a laptop.  Now I’m doing a dual-core server.

The first thing I noticed that is different from my usual installation process is that the asknetwork boot option to anaconda doesn’t work.  The boot process never asks for the network configuration.  However, applying the network configuration manually as boot options works as a workaround.  So the F16 command line options are now the following:

askmethod ip=<addr> netmask=<mask> gateway=<addr> dns=<addr,addr> noipv6 noselinux selinux=0

I don’t use IPv6 behind the firewall because I don’t need it yet.  I supposed I’ll be forced into it eventually, but for now this still works.

Also, the boot process hangs doing something with systemd.  After setting the boot options and hitting enter, the boot process blanks the screen and then just sits there for quite a while – perhaps a couple of minutes.  If this happens to you, be patient.  Systemd eventually times out and logs an error about “no such directory”.  After that, the install process continues as usual.

I actually have a very detailed process on how I do my upgrades that I need to put on my wiki.  Well, eventually.

Related posts

• No related posts.

I ran into an interesting problem today.  I have a C application with functions calling writev() to send data across the network.  The messages being sent range from very small – a few bytes – to over 1MB.  These functions have worked great up to this point.

Today I integrated a number of high resolution timers.  When the timers go off they raise a signal which is handled by a signal handler.  It turns out that writev() can be interrupted by these signals.  Unfortunately, it doesn't seem to recover correctly from that interruption.  I haven't figured out why, but I did find out that send() does recover correctly.

Since I don't need the feature provided by the iovec structure writev() uses there was no need to keep it.  So I switched to using send() in these functions, along with wrapping the call inside a loop to guarantee the full message was sent.  See, the signal causes the send() to return early, but it returns the number of bytes it actually wrote.  So you can catch that it didn't send everything and just try resending whatever is left. 

This works great and is not affected by the frequent signals.  This was interesting only because I didn't see anything in the man pages warning me about the problems with writev() and signals.  But at least now I know what to do if I hit this problem again.

Related posts

• Working with timer_create() to use multiple timers using a single signal (0)

The man page for timer_create() (used in applications, not in kernel code) gives a useful example of how to create and start high resolution timers.  However, it fails to mention that if you use multiple timers with a single signal then you need have a single signal handler that can identify which timer just went off and pass control to the timer-specific handler.

The way to do this is as follows.  Start with a function that creates and starts timers, makeTimer(). 

static int
makeTimer( char *name, timer_t *timerID, int expireMS, int intervalMS )
{
    struct sigevent         te;
    struct itimerspec       its;
    struct sigaction        sa;
    int                     sigNo = SIGRTMIN;

    return(0);
}

The function takes a pointer to a timer_t variable that will be filled with the timer ID created by timer_create().  This pointer is also saved in the sival_ptr variable right before calling timer_create().  In this function notice that we always use the SIGRTMIN signal, so expiration of any timer causes this signal to be raised.  The signal handler I've written for that signal is timerHandler. 

static void
timerHandler( int sig, siginfo_t *si, void *uc )
{
    timer_t *tidp;
    tidp = si->si_value.sival_ptr;

    if ( *tidp == firstTimerID )
        firstCB(sig, si, uc);
    else if ( *tidp == secondTimerID )
        secondCB(sig, si, uc);
    else if ( *tidp == thirdTimerID )
        thirdCB(sig, si, uc);
}

The handler checks that the value stored in sival_ptr matches a given timerID variable.  The sival_ptr is the same as the one we set in makeTimer(), though here it lives in a different structure.  Obviously, it got copied from there to here on the way to this signal handler.  The point is that the timerID is what is used to determine which timer just went off and determine what to do next.

All that's left is to create a timer.  Here's an example.

timer_t firstTimerID;

static int
srtSchedule( void )
{
    int rc;
    rc = makeTimer("First Timer", &firstTimerID, 40, 40);
    return rc;
}

This schedules a timer to go off every 40 milliseconds.  On my board (an embedded PowerPC-based board) the high resolution timers have a resolution of 4ms (see clock_getres()) so 40ms shouldn't be a problem.  The callback associated with this timer, firstCB(), is not shown here because it's specific to the application.

There is a lot of other stuff you can do with these timers.  You can check if the time overrun should cause an adjustment in the timer.  That helps sync with the real time clock.  Also, as with interrupts in the kernel, you should keep signal handlers fast and efficient.  Don't do anything that takes a very long time to complete.  Typically giving a thread a kick to do something should be sufficient.  But that really depends on your application.

Related posts

• writev() vs send() when using signals (0)
• VMware Server 2.0.1 on linux 2.6.29 (0)
• Peek ordered, learning about the hardware (0)
• Interesting stuff, nothing major (0)
• Intel driver updates: 2.5.99.2 and 2.6.0, plus a little about DRI2, Compiz and GEM (0)

I'm installing on an Asus A53S at work using Fedora 14.  I won't use Fedora 15 until they clean up the GNOME 3 fiasco (I want my old workflow, not something cool just to be cool).  The installation fails when it tries to launch X.  If you don't want a stripped down system (ie by using the "text" option to the boot commands) then you need to use the following options to get a standard VESA display.

blacklist=nouveau xdriver=vesa usefbx

The first option disables use of the open source nVidia driver.  The second tells the installation to use VESA but without the framebuffer driver you still may not get things working.  Leaving any of these out can cause the X display to lock up.  At least this way you get a full X environment, after which you can attempt to get nVidia's drivers working with this.

Related posts

• Linux Hardware Compatibility – getting started with off the shelf hardware. (1)
• The Everyday Guide to Fedora Upgrades (2)
• Preparing for Fedora 11: Installation on the Acer laptop (5)
• Intel driver updates: 2.5.99.2 and 2.6.0, plus a little about DRI2, Compiz and GEM (0)
• Fedora 14 mini review (0)

It's rather late, but I finally uploaded the images from this years village setup.  The images are not as good previous years because I just didn't have the time to set up the shots.  Ah well.  I'll do better in 2011.

New images are ready for browsing.  I've also updated the list of buildings we have by listing the North Pole Village items.

Related posts

• 2010 – Dickens Village and North Pole Series finds a new home (0)
• Less Geek, More Art (0)
• 2009: Dickens Village 2 (0)
• 2006 Design Overview (0)
• 2006 Dept56 galleries online (0)

This past weekend I completed verification that the build works on Ubuntu (see below).  In this process I also cleaned up the component builds a bit, added documentation and verified that a build from scratch (no local archives) works correctly.  And it does.  The resulting packages provide a booting system on a BeagleBoard C4 up to a terminal window (rxvt) running under a modified Matchbox UI.  But there is no video playback yet.  Various issues with DSP support exist and while I try to resolve those I'm looking at getting omapfbplay (via libav) working. 

For those wanting to get started with BeagleBox, following these instructions.   I wrote these instructions for a user in the UK who is interested in BeagleBox running on Ubuntu, but they map to Fedora to except that I don't have a fedora.notes file with prerequisite packages yet.  Let me know if you try this on any other distros.

Getting Started with BeagleBox

• Go to https://gitorious.org/beaglebox/beaglebox/trees/master/docs
• Download the following files:
  • README
  • ubuntu.notes
  • bashsetup.sh

Read the README file.  It will tell you what to do next.  Let me know if you have any problems.  I'll be happy to fix them.  Build takes about 2-3 hours on a dedicated dual-core AMD Athlon II X2 @ 3GHz, but that also depends on your pipe to the Internet since it has to download a boatload of software.

FYI – the build comes up to a Matchbox UI with a terminal on the HDMI port at 1280×768.  No video playback yet.  I've found that the DSP stuff may not be ready for prime time.  For now, I'll focus on getting omapfbplay running.  It utilizes the NEON support in the processor for playback, which is what the SuperJumbo distribution appears to be using.

Related posts

• BeagleBox: working Xorg and eth support (0)
• BeagleBox: SGX libs build, parts ordered, speeding up boot times (2)
• BeagleBox: Buildroot 2011.02 progress (toward video playback), Ubuntu and Linaro (0)
• Happy Holiday: Lilliput and HDMI monitors, another WD archive (2)
• BeagleBox: XComposite enabled under QEMU (0)

I've managed to build and boot Buildroot 2011.02 using the 2.6.32 Arago kernel and Crosstool-NG 1.8.2 with GCC 4.4.3 and uClibc 0.9.30.2.  The build works just as well as the older Buildroot 2010.11 I had been using, but there is a problem with where fonts are being installed.  For some reason the build tosses them under a sysroot tree based under my home directory on the target root file system.  Needless to say the runtime can't find these. There is a patch available that may address this (though I think the || should actually be an &&) but initial tests show it doesn't help.   I'm still trying to figure it out.  Once I get past this issue I may be able to have an xterm come up properly.  That would be a big step forward.

The 2011.02 release is an important milestone for BeagleBox because it includes the DSP utilities required to utilize the OMAP support for video playback.  This means I don't have to worry about trying to manually integrate the DSP support into my build system – Buildroot already has it.  So theoretically I will be able to play video as soon as I get the fonts problem fixed.  And that would be a huge step for BeagleBox!

While working to get 2011.02 built I ran into a few minor issues.  At one point I posted a bug report and the response came back that I was using a very old uClibc.  Turns out that's true.  But the problem is that newer uClibc's are not fully tested with Crosstool-NG (which is responsible for building this library).  uClibc 0.9.31 is marked as experimental in Crosstool-NG 1.8.2 (the default for BeagleBox at the moment) and 1.10.0 (tested using the XR= option on the command line for BeagleBox – testing new releases is pretty easy this way).  Both offer the chance of using a "latest snapshot" too.  A variety of tests were run with those but it turns out 0.9.30 was able to build Buildroot 2011.02 without error, but the others did not.  This is very possibly a problem with the mix of binutils, compiler and c-library I tried and further testing should be done.  For now, I have a working combination that I can stick with to get to the video playback testing.

Also, kernel 2.6.38.2 is said to have all the OMAP support required for BeagleBoard other than the SGX bits.  I tried using that kernel but it locks up right after uncompressing the kernel.  I have no idea why yet and more testing is definitely required.  It may be because I compile the kernel with some xM config options that are not compatible with my C4 board.  But I'm not clear what options those might be.  So BeagleBox with the latest kernel is still a wish list item too.  I've got the org repository for the kernel configured for 2.6.38.2 as the default for that repo, but that repo is still not the default for the BeagleBox build.  Also, Robert Nelson has the patches for SGX on the 2.6.32 kernel but does not (to my knowledge) have them ported for 2.6.38.2 yet.  I may look at that later but 3D support is a low priority at the moment.  Anyway, the 2.6.32 kernel is still the default so until 2.6.38.2 works properly it's a non-issue.

I still have to get the current block of updates pushed to git.  I'll do that today or tonight.  I'm currently waiting on a Buildroot test to complete.

In other news…

I haven't had many people ask to participate in BeagleBox yet, though I welcome any help.  However, a company in the UK that makes set top boxes thinks BeagleBox may be the best way forward for them in the long term.  They've used the SuperJumbo distribution to verify video playback capabilities (and are now looking at a slightly different OMAP chip because of that).  But they feel BeagleBox may provide the most flexible build for their specific needs.  Before they can be sure, they've asked me to get BeagleBox working on Ubuntu.

I tried to do the builds under a KVM session using Ubuntu 9.10 and 10.10.  In both cases the I/O throughput was so bad as to make the build unusable.  I'm no VM expert and don't have time to dig deeper into it, so I've punted and decided to throw more hardware at the problem.  I ordered another build system that I'll install Ubuntu on.  That should be here Monday or Tuesday.  I already know that the Fedora 13 specific patch in the xcc (cross toolchain) directory will need a platform specific test.  I expect I'll strap lsb_release -i | cut -f2 -d":" into the config.mk to identify the platform and then use platform specific patch directories under each component tree.  Shouldn't be a big deal to get it working though since there aren't a lot of platform specific issues other than making sure we have an up to date native toolchain.  Make 3.8.2 may be an issue, but I'll deal with that when I get there.

Note that Crosstool-NG has a new web site: http://crosstool-ng.org/  This is rather sparse at the moment though does provide downloads and will eventually have the original sites content migrated over, at which time downloads will only be available from the new site.  I'll be updating BeagleBox to point to the new site shortly.

And finally….

I've been looking at the Linaro releases to see how those might be integrated into the build.  Obviously the best route is to integrate Linaro with Crosstool-NG and Buildroot where applicable.  At the moment it isn't clear to me how this might be accomplished, but I'm only just starting to dig into it.  While most of the upstream push is intended to make desktop distributions happier I think there is another void to fill in making sure the embedded builds pick up on this.  They're already supporting the bigger players like OpenEmbedded and Yocto/Poky.  But I don't (yet) see much work with Crosstool-NG or Buildroot.  At least not on the maling lists.  So there is work to be done here, and I'm sure it will be a benefit for everyone once it happens.

Update:

I fixed the sysroot problem but even with fonts in the correct locations xterm still doesn't start.  I ran strace on it but that isn't telling me much.  So that problem still needs to be fixed.  I don't think any other apps will start up without it, though I can try things like surf or some other light weight browser.  But at least Buildroot 2011.02 is integrated.   Time to close FS#93.

Update 2:

The xterm problem remains unsolved, but I created a package for rxvt for buildroot and tested that and – viola! – it works!  I now have a terminal up running under BUI.  Big step forward!  With this I was also able to verify that the display is properly set to 1280×800.  Woohoo!!!  I'm psyched.  You have no idea how long I've been waiting to get to this stable point.  Next up:  test the video playback to see if that "just works" and then attempt to get the network configured.

Related posts

• BeagleBox: reality sets in – boot issues (0)
• BeagleBox: working Xorg and eth support (0)
• BeagleBox: SGX libs build, parts ordered, speeding up boot times (2)
• BeagleBox: kernel update, BUI initial release and analysis progress (0)
• BeagleBox: small steps – better xcc, u-boot/kernel boot but rootfs still hangs (1)

A recent thread on the Buildroot mailing list about the use of Buildroot in practice got me thinking about why I created BeagleBox and similar systems at work.  So I wrote up a paper on it and put it on my wiki.  Comments and criticicisms are welcome.

Related posts

• BeagleBox: working Xorg and eth support (0)
• BeagleBox: Buildroot 2011.02 progress (toward video playback), Ubuntu and Linaro (0)
• BeagleBox: XComposite enabled under QEMU (0)
• BeagleBox: SGX libs build, parts ordered, speeding up boot times (2)
• BeagleBox: reality sets in – boot issues (0)