Category Archives: Power Users

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.

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.

How to build software using CMake

I looked for easy instructions for building a package that uses CMake, so that I had a link to refer someone to. I couldn’t find one offhand – most seemed to be about creating a CMake-based build for your project, rather than using one that already exists. While building your own project with CMake is the next logical step if you do development, you’ll probably end up needing to build someone else’s first, so here’s a quick screencast (fairly Windows-centric) on how to get that done, including how to find dependencies.

Quick Tip: Recording Audio with Java-based screencast apps on Win 7 x64

I’ve been looking at some web java-based screencasting apps, namely screenr and  Screencast-o-matic, which look suspiciously similar. I wanted to record a voiceover along with a screencast, but couldn’t get it to work – on a Windows 7 x64 machine with 64-bit Java 7 installed (as well as I think 32-bit Java 7).

Long story short, the only way I could get either tool to recognize the fact I had any sound recording devices at all was to run it in Internet Explorer 64-bit (heaven forbid!). Hopefully this helps someone – if you know why this is, I’d be curious to find out.

A bit of quick Git scripting

Git is a slick revision control tool – if you haven’t used it yet, check out (IMHO) the best resource/tutorial on it: the Pro Git book.

Not only is it slick for people to use, it’s also really easy to write shell scripts to do repetitive work for you. The two examples I’m showing today come from my work on VR Juggler.

Moving branches between equivalent but not matching git-svn clones

I had been working with the VR Juggler source code using an automated git-svn mirror for some time (run using Jenkins and the scripts in my jenkins-svn2git repository), which worked pretty well. At least, a lot better than when I was just using SVN directly, since I don’t have commit access on the project. Eventually, upstream decided to switch to git (yay!) which they did a nice job of doing (authors all right, branches, tags, etc.), but now I had a problem – since they didn’t use git-svn exactly the same way I did, they had no commits in common with my mirror. (In addition to the authors thing, in this case, they had a https google code svn address, and mine was the http anonymous address.) I wanted to be able to relatively easily move my “work in progress” branches from my old mirror to the new official one (so that they branched from the same original SVN commit), so I wrote a little script to do it. Step 0 is to add the new official upstream as a remote to a clone of your own repo and fetch. You’ll see a no commit commits warning which you can smile and ignore. I made a fresh clone so that if something went wrong, nothing was lost.

I’ve posted my git-svn port-branch script as a Gist for your enjoyment and use. It’s easily the most involved git-related script I’ve ever written, but it follows essentially just these steps:

  1. Accept up to two inputs:
  1. <newupstreambranch>: the name of the new upstream (remote tracking) branch where we’ll be able to search the log to find a good commit to move to
  2. <yourbranch>: the name of the branch you’d like to move. (If the latter isn’t specified, the currently-checked-out branch is used.)
  • If the branch <yourbranch> doesn’t exist as a local branch, create it from origin/<yourbranch>
  • Use git log to find the most recent parent of your branch that includes a “git-svn-id:” line, and save that commit hash
  • Extract a portion of the git-svn-id: line (everything after the domain name), and search the history of <newupstreambranch> for a commit that includes that text. If everything goes right, this should be the “new” git equivalent of the same svn commit as the git commit found in step 3.
  • Do a git rebase –onto to transplant the non-svn commits over to the new parent.

Forward/backporting feature branches automatically

I’m used to the process of working on a fix, getting a nice topic branch with just those changes, then using a bug tracker/pull request/git format-patch to submit them. On some projects, such as VR Juggler, patches are most appreciated if provided in matching form for both the development version (master, formerly trunk) and the stable maintenance branch (in this case, 3.0). I had done a fairly mechanical process of a git rebase –onto to transplant my topic branches back and forth for some time. Since I had accumulated a number of unsubmitted patches, however, I realized I should just automate the process.

Thus I present another shell script as a Gist: automatically forward-ports or backports your patches in topic branches. This one is more likely to need a little manual tweaking for use outside of VR Juggler, since I wanted it to figure out whether I was porting from 3.0 to master or vice-versa, but it’s a definite timesaver. Its basic process is the following:

  1. Figure out whether the branch we’re porting is for stable or development based on the name. (probably could have used merge-base or something, but this gets the job done)
  2. Compute the name of the root branch we’re porting from, the name of the root branch we’re porting to, and the name of the topic branch we’ll create.
  3. Create our new branch at our old branch.
  4. Do a git rebase –onto of our new branch to change its parent.
  5. And, for my own ease of bug filing, if the user name is rpavlik, echo the github compare URLs that I’ll paste into the report.  🙂

NVIDIA GPUs and Product Series Cross-reference

Video card manufacturers mastered the complicated-model-number trick long before the CPU manufacturers did. I can never remember the order of the NVIDIA GPU codenames and what series they correspond to, so I’m posting this as a note to self and Google.  Based on primarily on information from: and

I do update this from time to time with new data.

  • NV4x
    • GeForce 6xxx series (and the 7100GS)
    • Quadro FX 1400, 3400, 3450, 4000, 4400 – GPUs referred to as NV4xGL
    • Quadro NVS 285 (NV44)
    • Sequential with the rest of the NVxx, where the first digit denotes the generation, and the second digit is arbitrary.
    • Latest supporting driver is the 304.xx series.
  • G7x
    • GeForce 7xxx series (except for 7100GS)
    • Quadro FX 350, 560, 1500, 3500, 4500, 5500 – G7xGL
    • Latest supporting driver is the 304.xx series.
  • G80 (series also includes G84, G86, and to a degree, G92, G98)
    • GeForce 8xxx series
    • Quadro FX 370 (G84GL), FX 570 (G84GL), FX 1700 (G84GL), FX 4600 (G80GL), FX 5600 (G80GL), VX 200 (G92), NVS 290 (G86)
    • G98 is a low-budget replacement for G86 and unfortunately shared model numbers in the GeForce series.
    • G92 (8800 GT) is a successor/peer for high-end G80 GPUs as found in 8800 GTS/GTX
    • First series to support CUDA – mix of compute capability 1.0 and 1.1
    • Most are PCIe x16
    • Quadro FX 470, 570, 5600 PCIe 2.0 x16
    • Supported by latest drivers.
  • G92a/b, G94a/b, G96a/b, G98
    • GeForce 9xxx series, GeForce 1xx series, parts of the GeForce 2xx series
    • Quadro FX 370 LP (G92), FX 380 (G96), FX 3700 (G92), FX 4700 (G92), NVS 295 (G98), NVS 420 (2x G98), NVS 450 (2x G98)
    • Compute capability 1.1
    • Most are PCIe x16
    • Quadro FX 3700, 4700×2 and VX200 are all PCIe 2.0 x16
    • Supported by latest drivers.
  • GT200, GT216, GT218
    • Parts of the GeForce 2xx series, parts of GeForce 3xxseries
    • Quadro FX 380 LP (GT218GL), FX 3800 (GT200GL), FX 4800 (GT200GL variant D10U-20), FX 5800 (GT200GL variant D10U-30), CX (GT200GL variant D10U-20), NVS300 (GT218)
    • Compute Capability 1.2 on GT21x, 1.3 on GT200a/b
    • PCIe 2.0 x16
    • Supported by latest drivers.
  • GF100, GF104, GF106, GF108
    • GeForce 4xx series
    • Quadro 600 (GF107GL)
    • Quadro 2000 (D), 4000, 5000, 6000 (all GF100GL)
    • Quadro Plex 7000 (two Quadro 6000)
    • First-generation “Fermi” cards
    • Compute capability 2.0 (GF100), 2.1 (others)
    • PCIe 2.0 x16
    • Supported by latest drivers.
  • GF110 (also GF114, GF116, GF117, GF119, and somehow GF106 and GF108?)
    • GeForce GT/GTX 500 series
    • GeForce 710M, GT720M, and 820M
    • Quadro 7000
    • Refreshed “Fermi” – lower power consumption, more functionality enabled
    • PCIe 2.0 x16
    • Supported by latest drivers.
  • GK1XX and GK2XX
    • GeForce 600 series except for 605, GT610, GT620, GT 625, GT 630, GT 640, GT 645 which are rebadged older cards. (Arghh!)
    • GeForce 7xx and 7xxM series, including GeForce GTX Titan and GeForce GTX Titan Black, except for 710M and GT720M mobile cards
    • GeForce GTX 870M, GTX 880M, and some GeForce GTX860M are also Kepler based.
    • Quadro K600, K2000, K2000D (all GK107GL)
    • Quadro K4000 (GK106GL), K5000 (GK104GL), K6000 (GK180GL)
    • Quadro NVS 510
    • Kepler cards
    • Most are PCIe 2.0 x16
    • GeForce 7xx series, most of GeForce 7xxM, and Quadro K6000 are PCIe 3.0 x16
    • GeForce GT730M, GT735M, and some GT740M (GK208-based, similar to GK107) are PCIe 3.0 x8
    • Supported by latest drivers.
  • GM1xx
    • Maxwell architecture
    • GeForce GTX 750 family (GM107)
    • Supported by latest drivers.

Recommended PPA + Third Party Repositories

I’ve been setting up a number of new Ubuntu installs recently, and so I thought it would be useful to record somewhere the Personal Package Archive (PPA) and third-party repositories I frequently use. You can add any of these with sudo add-apt-repository or by pasting them into the add repository dialog in Software Sources.  I have all these enabled on Lucid successfully, but no guarantees that they will all successfully coexist without breaking things on your system, Lucid or otherwise.

  • General Software
    • ppa:chromium-daily/stable – the Chromium stable channel. If you prefer the Google Chrome version, try:
    • deb stable main – The Google Stable channel. For the key, look at
    • ppa:sevenmachines/flash – 64-bit Adobe Flash, install package “flashplugin64-installer”
    • ppa:libreoffice – Updates to LibreOffice, the future of OpenOffice.  Still incredibly slow, but sometimes it’s all you can use.
    • ppa:ubuntu-wine – The latest Wine stable and dev releases.
    • ppa:lucid-bleed – If you want lots of backports to Lucid, this is the repo to enable.
    • ppa:maco.m/ruby – Updated version of rubygems
  • Graphics (XOrg, drivers) Improvements
  • Programming-related
    • ppa:kubuntu-ppa/backports – Backports of newer Qt versions including Qt Creator.
    • deb lucid/ – Updates for R from the ISU CRAN mirror.  If you’re not using Lucid, change the release codename in this line
    • ppa:pyside – PySide is the LGPL replacement for PyQt that works pretty well. It’s under plenty of development so the PPA is useful.
    • ppa:git-core – Updates to the Git version control suite.
  • VR-Related – Of course I had to plug some of the PPA’s I maintain for the lab. Help maintaining these is always welcome!
    • ppa:isu-vrac/osg – Updated versions of OpenSceneGraph.
    • ppa:isu-vrac/vr-software – VR Juggler and its dependencies.

Enabling the hardware power button in Ubuntu Server 11.04 (Natty)

Just a quick note for my reference and for Google: If you want your Ubuntu Server machine to respond to the power button, you have to install acpid first.  Once installed, it will run by default (and start up during the install process), so the power button should be functional from then on.  This should also create the /etc/acpi directory and scripts that folks mention when discussing Linux power management.

Credit where credit is due: figured it out from this bug report resolved as INVALID with this workaround which, while old, still applies to the latest Ubuntu release.

Setting a “Task Manager” keyboard shortcut in GNOME

If you’re much of a Windows user, you’re probably aware that Ctrl-Shift-Esc will quickly open the task manager there, which is a handy thing to be able to access quickly – take care of an out-of-control app, see what’s pulling so much CPU power, etc. On GNOME (for instance, Ubuntu Linux), the System Monitor does the same task, but there’s no equally quick way to open it by default. You can add the system monitoring applet to your panel which will give you one-click access, but if you’re like me, you find yourself reaching for Ctrl-Shift-Esc first anyway.

Without further ado, how to make Ctrl-Shift-Esc do the same thing! (This is on Ubuntu Lucid, but should be pretty similar on most GNOME desktops.)

  1. Open the Keyboard Shortcuts control panel. For me, it’s in System, Preferences. (This is a per-user setting.)
  2. You might want to collapse all the existing groups so you can see where your new item will be added.
  3. Click “Add”, and enter:
    • Name: System Monitor
    • Command: gnome-system-monitorCustom Shortcut Window
  4. Click on the newly-added entry, and press Ctrl-Shift-Esc to record the new shortcut.Keyboard Shortcuts Window
  5. Close the control panel and try it out!