Category Archives: Articles

Graphics Driver Headaches

Nothing like computer problems when you’re trying to wrap up your dissertation to really make your day…

Quick tl;dr version: I’ve had a lot of problems with NVIDIA Linux drivers 337.x and even more with 340.24, at least on dual Quadro K600 cards driving four displays using basemosaic. No such problems under 331, but Debian didn’t package the 331 update that supports the current xorg-server ABI. I took their 331.79 package and updated it with the upstream 331.89 version, which fixes a few bugs, adds two PCI IDs, and adds support for the newer xorg-server ABI. Here are the source package, as well as the build results from my i386 and amd64 jessie cowbuilders. Use at your own risk, but they work great for me so far. You’ll have to pin the versions otherwise it’ll try to upgrade after you install them.

The standard disclaimers (no warranty, not responsible for problems, crashes, nasal demons, etc) apply: use at your own risk.

After the jump: deb packages, source packages, source debdiff, problem description, process, and lessons learned.

Continue reading

Building xpra on RHEL6 as a normal user

Xpra is described as “screen for X”, and while that’s true, I’ve never really used GNU screen much. What I use it for, though, is provide a much faster substitute for X forwarding (even on a local network).

I have access to a nice machine that I’d like to work remotely on. Two catches: I’m not root, and it’s running RHEL6 with minimal extra package repos. To install software locally, I use GNU stow along with some nice setenv action in files sourced by .cshrc. Here is what I was able to do to get Xpra running at a minimum capacity.

Note: $STOW is whatever your stow directory is – all the stow documentation essentially assumes that it’s /usr/local/stow, but in my case it happens to be (wait for it) /home/users/rpavlik/linux/stow/rhel6/stow. Yes, I could have probably chosen a location with a shorter pathname, but inertia makes it not worth changing at this point. I’ll use $STOWPREFIX to refer to wherever stow links things into, usually the parent directory.

  1. I asked my friendly department IT folks to install the dependencies from – which in my case, wasn’t exactly what happened since EPEL or other package repos are off-limits, but I ended up with whatever the latest official versions are of those dependencies for RHEL6.
  2. Grabbed Cython 0.20.1 since the RHEL6 Cython is too old. Copied the contents of the tarball into $STOW/Cython-0.20.1/lib64/python except for the bin directory, which instead went became $STOW/Cython-0.20.1/bin. Stowed Cython-0.20.1 – note that this is a build-time dependency only (I think).

  3. Made sure that I had my PYTHONPATH environment variable set to include (it may be empty to start) $STOWPREFIX/lib64/python. On the next login, I checked that which cython and cython -V reported values that I expected.

  4. Grabbed Xpra 0.11.6 and unpacked it. I initially built without a lot of ffmpeg/libav stuff, but it turns out that there are patches in the source tree to handle old versions. I patched with these commands:

    • patch -p1 < patches/old-libav-pixfmtconsts.patch (replaced --without-csc_swscale flag)
    • patch -p1 < patches/old-libav-nofree.patch (replaced --without-dec_avcodec flag)
  5. In the source directory, I ran ./ install --home=$STOW/xpra-0.11.6 -without-vpx which almost worked except for one place where it tried to write to /etc. I applied this trivial patch to correct that.

Adding --without-client to the build command is an option I considered since I typically use this home directory on a headless machine, but it’s shared with headfull machines which I might want to use as Xpra clients someday.

And…. that worked! I had to run with --no-mdns since I didn’t apparently have the Avahi mDNS python module installed on the system, but that’s a minor issue easily worked around.

Avoid distraction on Stack Exchange sites

If you’re like me, you’ve found a great deal of value in the information on the various Stack Exchange web sites (Stack Overflow, Super User, Server Fault, etc.). However, recently, in an effort apparently to improve traffic to questions on other sites, they’ve added a section to the sidebar with links to completely unrelated questions in other Stack Exchange sites (the so-called “Hot Network Questions”).

The catch is, when I am on these sites, I usually don’t want an unrelated rabbit hole to go down. Turns out it’s simple to disable that, you just need a “user style” – kind of like a user script (Greasemonkey, etc.) I have made one and posted it here: It’s minimal, but “does what it says on the tin”. Enjoy!

Drat – SparkleShare unofficial PPA includes breaking update

The SparkleShare unofficial PPA contains a python-gobject update that breaks a number of things, including software center/update manager, gedit plugins, etc. On the page for this PPA it does now mention that it’s not recommended for Ubuntu Precise 12.04 – but it’s a bit too late for me to avoid issues.

What’s more, ppa-purge ppa:rebuntu16/sparkleshare+unofficial doesn’t seem to work – it tries to remove most of the packages installed on my system. Same result when trying to force versions with Synaptic. Thus, I unfortunately had to write my own little tool, using python-apt. It asks for no confirmation, and the only test is that it worked on my machine. Consider this fair warning. The script is here.

Run the script to apply the changes, then edit your sources.list or sources.list.d to remove this source, sudo apt-get update, and check in Synaptic to make sure you didn’t miss anything (which would now show up in the Status panel under “Installed (local or obsolete)”).

If anybody wants to help make this an improved replacement for ppa-purge, please let me know and I’ll fork it into a real GitHub repo instead of just a Gist.

Visual Studio 2012, XP support, and codebases with too many dependencies

The potential of C++11 support first enticed me to consider moving to Visual Studio 2012 for Windows development. (Our existing environment was Visual Studio 2008.) Once I got a moment to actually try it out, the much-improved IntelliSense (that actually debuted in 2010, powered by a modern, capable compiler front-end, EDG) really wooed me. It’s remarkable what not getting flustered by a smart pointer can do for code completion.

Here’s the rub: We have a large immersive system that runs Windows XP x64, and for a research lab that develops software in the course of its work (rather than a software-driven shop), we’ve got a bunch of dependencies. VS2012 does support Windows XP, kind of, but you have to jump through some non-default hoops to get it to work.  I’m happy to announce, however, that I was able to get the whole stack we use for VR JuggLua built with VS2012 using the “v110_xp” XP-compatible toolset. (The linked page has the details on how to check/set the Platform Toolset of VC projects for XP compatibility.)

By far, the easiest way to build is if you have a CMake-based build system available. Recent versions of CMake have added a “Generator Toolset” concept, which can be used to specify the “v110_xp” toolset needed for this instance. There’s no GUI support for this at the time of this writing (CMake, but it can be done in the GUI: before initially configuring a build, add a string variable to the cache called “CMAKE_GENERATOR_TOOLSET” with the value “v110_xp”. You might see a spurious warning about this not being used at generation time, but rest assured, it is. (Check in Visual Studio if you’re not confident.)

VR Juggler and its dependencies have been built and posted (as branches) in my vrjuggler-windows-binaries repository. The linked branch includes VR Juggler 3.0.x (built from my CMake-enabled git branch, using CMake) as well as the client-code compile-time dependencies. In separate branches, I’ve preserved all the dependencies separately:

I’ve also built OpenSceneGraph, with a usable subset of its plugins. Conveniently, I realized that third-party libraries with a C-only interface can be built once with MinGW and used across compiler versions (as Zlib does), which helps a lot. (Particularly with the CMake option to spit out an MS-compatible .lib import library file.) I’ve uploaded the OpenSceneGraph 2.8.x v110_xp binaries here.  (Binaries in git repos let me use them as submodules…)

For VR JuggLua to build in all its glory, it needs Qt 4.x, or at least FLTK. FLTK was an easy build, and I got the chance to hammer out a few bugs in that neglected GUI frontend. I did end up being able to get Qt 4.x built, after a bit of pain and uncertainty as to whether it would actually work on XP. I’ll post binaries, or at least instructions, soon.

Did it work? Yep! Got a fully functional VR JuggLua build that successfully runs immersively in the aforementioned WinXPx64 system. It’s not the default for continuous builds (yet), but it’s a lovely step forward.

Making a CMake-based build install software in de-facto standard locations

This post falls partially into the “Note to self” category. I typically set up CMake variables for “bin”, “lib”, “share”, and so on to use when installing software (or building it if I want it to run in the build directory and it’s stubborn about layout). Turns out that there’s a module called GNUInstallDirs that was added to CMake in 2.8.5, and improved since then, that sets these up in a standard-ish way. Furthermore, when distros package CMake, if they don’t follow the defaults, they typically patch this file so it applies, so this really takes care of the whole “what to call the library directory” mess quite nicely.  The canonical source documenting the meaning of these variables comes from the GNU project, but I’ve separated the most common ones below (listed ready to copy-and-paste into your build):

  • ${CMAKE_INSTALL_BINDIR} aka “bin”
  • ${CMAKE_INSTALL_LIBDIR} aka “lib” or “lib64” or something more complicated for Debian multiarch
  • ${CMAKE_INSTALL_INCLUDEDIR} aka “include”
  • ${CMAKE_INSTALL_DATADIR} aka “share” – not sure what the difference between this and DATAROOTDIR is, but it appears nobody else does either, so I’m just gonna roll with it.

As a side effect, you’ll get a unixy layout on other operating systems too, but as I already was doing this, it’s cool with me.

If you mixed Git and Dropbox, and made it open source…

…you’d get SparkleShare. It automatically synchronizes directories to Git repositories, whether you host them locally or on some service like GitHub.

Now, don’t get me wrong: this isn’t how you want to do version control for your software, where meaningful commits are important.  This is more for “data” or “asset” files – I’ve seen it used for project artwork/icons, for instance. It can also be handy for managing an essentially static web site built with a tool like Jekyll. For those use cases, it can be a great tool, particularly for non-programmers.

I’ve recorded a screencast showing how to install (even as a non-admin) the app on Windows, set it up to link with your GitHub account (they handle ssh keys transparently in the background), and add your first repo. Enjoy!

[EDIT: Sorry, Screenr has gone away along with this screencast.]


[EDIT TO ADD]: Ubuntu includes SparkleShare in its repos, but it’s an outdated version (in all releases). A useful PPA to add would be this: Note that SparkleShare requires Git, and the newer the version of Git, the better your life generally is, so make sure you have the Git update PPA also enabled: . Something like this would add them for you:

sudo add-apt-repository ppa:rebuntu16/sparkleshare+unofficial
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
(optionally sudo apt-get dist-upgrade or other method of upgrading your git packages)
sudo apt-get install sparkleshare

SolidWorks to OpenSceneGraph

[Update March 26: Re-uploaded the tool, I had scaling backwards.  Oops!]

File format management seems to be a perpetual problem in CAD.  For folks looking to convert a SolidWorks assembly to use in OpenSceneGraph and maintain the position and orientation of the parts relative to each other, we’ve figured out what seems to be the ideal workflow, at least for now.  A nice feature: it doesn’t require any commercial, proprietary software beyond SolidWorks itself.  I’ve documented the process in two screencasts on my Screenr account, which I’ve embedded below.

Download the Windows tool used in the screencast here: osgconv-20130319-solidworks-stl

First step: Export files from SolidWorks to STL.

Second step: Convert STL files to OSG files in bulk.

Using C++ on the Arduino: a mainstream C++ Standard Library port for the AVR!

The Arduino development environment (and more generally, the avr-gcc/avr-libc/avr-binutils toolchain) supports, and in the Arduino core library, uses C++ language features.  However, a C++ standard library is not included, which makes using other C++ libraries (even just the header-only libraries in Boost) a challenge, and can result in less effectively-C++ code.  Among my goals in seeking C++ standard libraries for the Arduino include the ability to use the excellent Eigen matrix-math library and some of the header-only Boost libraries.

(tl;dr version: visit !)

A number of individuals have worked on ports of (partial – at least the Arduino IDE disables RTTI and exceptions, and fstream is little use without a filesystem) C++ standard library implementations. (Keep in mind that the C++ standard library is more than just the STL – the string library is sometimes considered part of the STL but is technically its own thing, as well as the streams library.)  The following are the previous attempts I’ve found:

  • Andy Brown ported the original SGI STL (not a full C++ standard library) but with some additions to bring it closer to a full standard library. He considered libstdc++ (too embedded with the desktop GCC toolchain) as well as uSTL (which he eliminated due to larger generated code size) before porting the SGI STL. He made a number of customizations to it that, while making it less standards-conforming, made it more suitable to use on AVR devices. He supplemented it with a streams implementation based on  uClibc++, as well as some custom features for the AVR and Arduino environment. (For instance, iostream implementations for HardwareSerial and character LCDs.) The library is header-only, so you only pay in compile time for what you use. However, the SGI STL precedes the standardization of the C++ standard library with STL (it’s an [the?] initial implementation…), so compiler and library compatibility are sometimes a bit sketchy.
    • The SGI STL license is a fairly liberal, non-copyleft license that Debian’s won’t identify for me :-). The portions from uClibc++ are LGPL 2.1+, and the headers written by Andy specifically for the arduino (lcdostream and serstream) are under a three-clause BSD license.
  • “maniacbug” started the Arduino library StandardCplusplus, a fairly direct port of uClibc++ . uClibc++ is a more modern implementation than the SGI STL (that is, it’s a post-standardization implementation) and aims to be a full C++ standard library.  I found that to use for my purposes, I had to make a number of modifications (particularly in implementing the limits header), which are on my GitHub fork of StandardCplusplus. It’s concise and easy to read, but its relative incompleteness in the areas I needed made it some effort to maintain.
    • License-wise, uClibc++ is LGPL 2.1+ which keeps it easy to move code in, but harder to move code out, and a bit confusing for embedded. (avr-libc uses, and seems to recommend, an MIT-style non-copyleft liberal license – presumably to avoid potential complexities over requirements and definitions of linking, derivative works, etc. given the nature of embedded code as being flashed into hardware.) The stream classes by Andy Brown were also added to this library, under the same three-clause BSD license mentioned earlier.

While I had gotten StandardCplusplus to a state where I could mostly use it, I found myself hitting a number of issues bit-by-bit. Furthermore, a number of the fixes/needed implementations were because of gaps in upstream, rather than porting issues, and the break between the upstream uClibc++ and the Arduino-layout, Arduino-specialized version made it harder to justify fixing issues that would be bothersome to port upstream and/or marginally likely to be accepted (AVR-specific code somewhat scattered, and behind ifdef __AVR__ or ifdef ARDUINO guards).

With this background, I’d like to introduce my new development, and what I’m using now: the addition of an AVR port to the STLport project, which I’ve posted on GitHub.  STLport is liberally-licensed, and evolutionarily, it descends from the SGI STL that served as Andy Brown’s starting point. However, STLport, despite its name, can be configured as a full C++ standard library. It has been extended, expanded to include newer C++ standards and TR1, and (as suggested by the name) ported to work with many compilers. This porting was done smartly, by limiting platform-specific macro checks to configuration headers, which define feature-focused configuration macros as needed for use in the rest of the library. This meant that my changes could be fairly limited in files touched: primarily adding a config header for AVR, modifying the GCC config header to avoid assumptions that are untrue on AVR, and creating/applying a few more feature-focused config defines to reduce the library’s size and porting overhead. While the last tagged release was in 2008, the project has been moved to a Git repository and has been under some development since then. For instance, changes to the STLport-5.2 (stable) branch are as recent as April 2012, and the master branch in fact is (working toward being) a C++11 standard library.

I’ve made ports for both the 5.2 stable branch and the master branch. The library can be built using the STLport build system if you prefer, though if you’re using Arduino, all you’ll need is one of the “arduino-installed” branches: these are generated by a script rearranging the sources/headers from the mainline branches. This way, they won’t fall (much) behind and can easily be reproduced. (I could have claimed success without these branches, however, I find it convenient to keep Arduino libraries in Git submodules, and the branch solution provides a straightforward, nontechnical way to use the library directly with the Arduino IDE.) Both the C++11 and stable 5.2 versions work with the Arduino core library, though note that you’ll need to put your compiler into C++11 mode for the master branch. As far as I can tell, this can’t be done with the Arduino IDE.

I’ve verified that both versions compile as a static library on their own. I’ve also verified that C++ Standard Library-using Arduino sketches build using (my branch of) Arduino-Makefile (with appropriate EXTRA_CXXFLAGS as needed) on both the master and 5.2 branches, and that sketches build successfully using the Arduino IDE and the 5.2 branch. My test system for this has been an Ubuntu Lucid x86_64 machine, with the following package versions updated from Debian Testing:

  • arduino and arduino-core  – 1:1.0.1+dfsg-6
  • gcc-avr – 1:4.7.0-2
  • binutils-avr – 2.20.1-3
  • avr-libc – 1:1.8.0-2

On Windows, I’ve been using the Arduino 1.0.1 IDE upgraded with Windows binaries of gcc-avr 4.7.0 and avr-libc 1.8.0 from Andy Brown (caveat: save your original avr-size.exe and put it back in place after). As this updated  is substantially the same as what I use on Linux, I’m pleased that as expected, building on Windows with the 5.2 branch in the IDE works just fine.  Remarkably, though the toolchain bundled with 1.0.1 on Windows is very very old (gcc 4.3.3) and contains some annoying-to-really-bad bugs for AVR, it at least built my (complicated template metaprogramming and STL algorithm-based) test app, only being slightly more picky about my nested template syntax.

So, give it a try! Let me know if it works for you – and if you have improvements, or find things that don’t work, please feel free to send an issue or pull request on my STLport for AVR/Arduino GitHub repository.


Bluetooth module and breakout for use with Arduino

SVG original version of the Annotated Diagram

PDF version of the Annotated Diagram