Firefox drops ALSA; apulse to the rescue

Once again I’m caught between a rock and a stupid place. Mozilla joined Harry Pottering and the eternal september of GNU/Linux, who carries on dead-set on tearing down everything simple and elegant in the userland, replacing it with crude immitations of the beast (MacOS X). So in an inspired move, firefox went bananas and dropped its ALSA audio backend with release 57. And everyone who doesn’t fancy spending 10% of their battery life on a byzantine audio contraption, is left with silent southpark, and kung fury without the awesome 80s synths and the buttery voice of David Hasselhoff.

I tried switching to chromium for a month, but I just couldn’t stomach it. Now I always maintained that if everyone switches to pulse audio, I can always make a pulse wrapper over alsa, but I really didn’t want to have to deal with that. Thankfully, I didn’t have to bother, because a guy called Rinat Ibragimov beat me to it, and wrote apulse: a thin libpulse replacment which works with ALSA.

So in theory running apulse firefox should be sufficient to have sound in firefox 57 again. Unfortunately I had to take some more steps, and since I’m certain I’ll forget all about them next time I’m trying to do the same on another computer, I’ll keep a note here of the extra steps I had to take, to make apulse work with firefox on my computer.

Proper Oculus Rift DK2 setup on GNU/Linux

This is a quick post about the proper way to set up the Oculus Rift DK2 on GNU/Linux, which might not be obvious for users not deeply familiar with the X window system.

Introduction

(feel free to skip)

I remember discussing this a long time ago in the oculus forums, back when the linux version of the oculus SDK was doing absurdities such as relying on Xinerama to detect and use the oculus display. Setting up the rift display as an extension of the desktop, is wrought with peril and woe. Thankfully, the X window system is awesome, and used to deal with such diverse multi-display contraptions, back when burly men programmed computers made of pumps, grease, and steel… true story.

Tutorial: Practical makefiles, by example

I know a lot of programmers, who are afraid of makefiles. Most of them come from a windows background, and when they migrate to GNU/Linux or MacOS X they naturally gravitate towards clunky IDEs to manage their build process. Others, fearing that makefiles are going to be too complex to manage manually, try to use even clunkier makefile (or project file) generators like cmake.

While none of the above solutions is without some merit in particular cases, I strongly believe that there’s no faster and simpler way to build your project, than writing a small makefile. And in order to dispel the fear, I decided to write a tutorial about how to write simple, practical makefiles, for your programs.

The article is too big and too … structured, for my idea of what a blog post should be, so I’m hosting it on my web site along with some of my previous articles instead.

So anyway here it is, let me know if you find it useful: Practical makefiles, by example.
Feel free to use the comments section in this post for any feedback, or send me an email if you prefer.

Btw, I used reStructuredText, and the docutils translators for this. So there’s also a PDF version, produced through the rst2latex translator. It’s not as good as it could have been if I wrote it directly in LaTeX, but I suppose it’s serviceable if you prefer a printable off-line version.

How to use standard output streams for logging in android apps

Android applications are strange beasts. Even though under the hood it’s basically a UNIX system using Linux as its kernel, there are other layers between (native) android apps and the bare system, that some things are bound to fall through the cracks.

When developing android apps, one generally doesn’t login to the actual device to compile and execute the program; instead a cross-compiler is provided by google, along with a series of tools to package, install, and execute the app. The degrees of separation from the actual controlling terminal of the application, make it harder to just print debugging messages to the stdout and stderr streams and watch the output like one could do while hacking a regular program. For this reason, the android NDK provides a set of logging functions, which append the messages to a global log buffer. The log buffer can be viewed and followed remotely, from the development machine, over USB, by using the “adb logcat” tool.

This is all well and good, but if you’re porting a program which prints a lot of messages to stdout/stderr, or if you just like the convenience of using the standard printf/cout/etc functions, instead of funny looking stuff like __android_log_print(), you might wonder if there is a way to just use the standard I/O streams instead, right? Well so did I, and guess what… this is still UNIX so the answer is of course you can!

Linuxtrack 6dof headtracking for wine games

Since I was a little kid, I always loved airplanes. When I became a little older, mainly during the 90s I used to play a lot of flight simulators on my computer, I even had a set of decent flight controls (stick/throttle), but for some reason I dropped that hobby for many years. Until I very recently picked it up again.

One really important thing that changed during my abstinence from flight simulators, a huge change that transformed the whole experience, was the almost universal adoption of 6dof headtracking for looking around as you fly!

Now people are able, with simple intuitive movements of their head to be able to look outside as they fly above that beautiful lake, “check six” to effectively maneuver to avoid an enemy plane in a dogfight, or follow the runway with their own eyes as the airplane turns slowly into final approach to line up perfectly for landing! Even better, since 6dof headtracking includes translation as well as rotation, the user can look around an obstacle blocking the view, to see for instance a pesky instrumment in the panel that’s partly hidden behind the stick, or a plane in formation which happens to fly just where the canopy frame happens to have a metal support bar. Just moving the head a bit to the left or the right does the trick… Unbelivable!

Instrumental for the universal adoption of 6dof headtracking among flight simulator users and developers, is a company called NaturalPoint who sells a complete head-tracking system called TrackIR, that includes an infrared high framerate camera, markers that the user attaches to their heads, and supplies an API to game developers to access their headtracking data easily. Now that set doesn’t come cheap, so there’s the necessary free alternative out there, that works with a simple (or even better modified) webcam, called freetrack. The main problem with both of those as you might have guessed, is that they only work on windows.

After the first dissapointment, I obviously had to have that functionality, so I decided to start hacking my old 3dof headtracking experiment to make it 6dof and connect it somehow with games running through wine. However, while I was researching how to do that, I stumbled upon the linux-track project, which does exactly what I needed, but it only worked with a native GNU/Linux flight simulator called x-plane.

So, with only a small piece of the puzzle missing, I went on and wrote a program that emulates the TrackIR API which is supported by many windows games, but feeds them data from linuxtrack instead. Currently I’m happily playing IL-2 Sturmovik and Falcon4 AF through wine, with full head-tracking support, enjoying the virtual view from my cockpit.

This new project of mine is called linuxtrack-wine and is available under GNU GPLv3.

I also had to do a hardware hack, to convert my old flight controllers from gameport to USB, but that’s much less interesting, and I’m too lazy to write about it right now :)

Serial Spaceball and Spacenavd

I finally got my hands on a serial spaceball device. Apparently non-USB devices are literally given away on ebay for ridiculously small amounts of money, so I managed to get this wonderful Spaceball 4000 FLX for 12 pounds a couple of days ago!

I wanted a serial spaceball for two reasons: first of all I meant to add support for serial devices to spacenavd for a long time now. In fact John Stone was kind enough to send me his code to interface with serial spaceballs a long time ago, but not having such a device myself, for testing, I wasn’t very keen to hack at it blindly. Also, I wanted to be able to use a 6dof input device with my SGI Octane2, which doesn’t have any USB ports.

So finally, as soon as I got my hands on the serial spaceball, I went on and added serial support to spacenavd. I haven’t released a new version of spacenavd yet, because I want to iron out some details first, but you can always get the new serial-capable spacenavd through subversion if you need it.

Wacom Hacking

Recently, I acquired a rather old Wacom Intuos A5 tablet, for reasons I won’t delve into at the moment.

It’s an old serial model, and although I don’t have a serial port anymore, I do have a USB-to-serial adapter, which thought would probably work fine with the X.org driver produced by the linuxwacom project, since they do mention support for serial tablets on their website.

I plugged it in, followed the linuxwacom documentation about setting everything up in xorg.conf, and fired up the X server. Nothing happened… So I started digging in the wacom driver source.

First Obstacle: Prolific PL2303 USB Serial Port

The first problem I encountered was with my USB-serial adaptor. Apparently, the wacom driver used a TCIOCGSERIAL ioctl, which is supposed to return information on a serial device, to determine if it’s talking to a serial or a USB device. If the ioctl fails, it thinks it’s not talking to a serial device, and starts talking USB HID to the tablet.

Unfortunately, the pl2303 driver in the linux kernel (as of version 2.6.32.8 that I tested) does not implement the aforementioned ioctl, even though it’s supposed to present a proper serial port to the system. So I had to hack the kernel, and add that ioctl in the pl2303 driver (patch against 2.6.32.8).

(edit: my pl2303 patch got included in linux 2.6.34, so you don’t need the patch any more)

Sadly however, although now the wacom driver realized that it was dealing with a serial device, the tablet still didn’t work…

Second Obstacle: The linuxwacom Driver

After a lot of digging around the source of multiple wacom driver versions, it turns out the guys at the linuxwacom project removed the code for old serial tablets from the driver sometime last year!

I tried installing a few older versions of the driver (anything prior to 0.9.1 had the serial code), but they would not compile with the much newer X.org headers in my system. Apparently some changes with the XInput extension broke the old driver. So I started hacking again.

First I tried back-porting the XInput changes from the newer wacom driver to the old 0.8.4 version, but although I managed to compile it, it would segfault upon being loaded by the X server. Evidently I screwed something up during the backport, which I could have probably fixed eventually, but I realized that it’s a bad idea to get stuck to the old wacom driver.

So instead I started from scratch in the opposite direction, re-integrating the old serial code from 0.8.4 to the most recent 0.10.4 wacom driver.

Success!

And indeed after a few hours of hacking, I managed to get my serial Wacom Intuos to work perfectly! Here’s the patch in case anyone needs it.

I must say it’s an impressive input device, pressure-sensitivity, tilt sensing, everything works perfectly. The only problem is that I still can’t draw any more than I could on paper :)

Spacenavd 0.4

I just released version 0.4 of my spacenavd user space driver for 6dof input devices, which fixes some long-standing reliability and ease of use issues.

First and foremost, I cleaned up the code, which started initially as a hack, and ended as an unmaintainable mess. I’ve split and isolated the linux specific parts so that I may add support for other operating systems in the future (specifically I’d like to find the chance to add freebsd support soon).

I’ve also dropped the dodgy 30sec polling cycle to aquire the device if it’s disconnected, which had the effect of being able to use the device at some seemingly random time after plugging it in, and started using the KOBJECT_UEVENT netlink socket to get asyncronous notification of hotplug events from the kernel. Now the device lights up and is ready to use immediatly upon plugging it in the USB port.

More importantly, I lifted the responsibility of notifying the daemon that X has started and it may connect and start listening for X11 clients from the user. By using the excellent inotify API to detect when the X server’s socket is created in /tmp/.X11-unix, the daemon is now able to wake up and connect to the X server automatically as soon as it’s started up.

And finally, now spacenavd actively grabs the device when it starts, which solves the problem of the X server trying to use it as a mouse, without having to resort to messing around with the user’s HAL config files, to make hald ignore it.

To celebrate this milestone release, the free spacenav project now has a newly redesigned web site, which may help attract more attention compared to the previous plain-text web page. Thanks go to cybernoid for the new web site.

Does vi rule or what?

I get really excited each time my favourite development environment (UNIX + vi), lets me perform a task of insurmountable tediousness, in a split second. So much in fact, that I can’t hold myself from sharing it with others. And since updates on this blog are scarce anyway, I decided to write about it.