Mir and Vulkan Demo

This week the Mir team got a Vulkan demo working on Mir! (youtube link to demo)

I’ve been working on replumbing mir’s internals a bit to give more fine grained control over buffers, and my tech lead Cemil has been working on hooking that API into the Vulkan/Mir WSI.

The tl;dr on Vulkan is its a recently finalized hardware accelerated graphics API from Khronos (who also proved the OpenGL APIs). It doesn’t surplant OpenGL, but can give better performance (esp in multithreaded environments) and better debug in exchange for more explicit control of the GPU.

Some links:
Khronos Vulkan page

Wikipedia Vulkan entry

short video from Intel at SIGGRAPH with a quick explanation

longer video from NVIDIA at SIGGRAPH on Vulkan


If you’re wondering when this will appear in a repository near you, probably right after the Ubuntu Y series opens up (we’re in a feature freeze for xenial/16.04 LTS at the moment).

Posted in Coding, mir, Multimedia, Ubuntu | Leave a comment

New Mir Release (0.18)

Mir Image

If a new Mir release was on your Christmas wishlist (like it was on mine), Mir 0.18 has been released! I’ve been working on this the last few days, and its out the door now.  Full text of changelog. Special thanks to mir team members who helped with testing, and the devs in #ubuntu-ci-eng for helping move the release along.


  • Internal preparation work needed for Vulkan, hardware decoded multimedia optimizations, and latency improvements for nested servers.
  • Started work on plugin renderers. This will better prepare mir for IoT, where we might not have a Vulkan/GLES stack on the device, and might have to use the CPU.
  • Fixes for graphics corruption affecting Xmir (blocky black bars)
  • Various fixes for multimonitor scenarios, as well as better support for scaling buffers to suit the the monitor its on.


  • Use libinput by default. We had been leaning on an old version of the Android input stack. Completely remove this in favor of using libinput.


  • Quite a long list of bug correction. Some of these were never ‘in the wild’ but existed in the course of 0.18 development.

What’s next?

Its always tricky to pin down what exactly will make it into the next release, but I can at least comment on the stuff we’re working on, in addition to the normal rounds of bugfixing and test improvements:

  • various Internet-o-Things and convergence topics (eg, snappy, figuring out different rendering options on smaller devices).
  • buffer swapping rework to accommodate different render technologies (Vulkan!) accommodations for multimedia, and improve latency for nested servers.
  • more flexible screenshotting support
  • further refinements to our window management API
  • refinements to our platform autodetection

How can I help?

Writing new Shells

A fun way to help would be to write new shells! Part of mir’s goals is to make this as easy to do as possible, so writing a new shell always helps us make sure we’re hitting this goals.

If you’re interested in the mir C++ shell API, then you can look at some of our demos, available in the ‘mir-demos’ package. (source here, documentation here)

Even easier than that might be writing a shell using QML like unity8 is doing via the qtmir plugin. An example of how to do that is here (instructions on running here).

Tinkering with technology

If you’re more of the nuts and bolts type, you can try porting a device, adding a new rendering platform to mir (OpenVG or pixman might be an interesting, beneficial challenge), or figuring out other features to take advantage of.

Standard stuff

Pretty much all open source projects recommend bug fixing or triaging, helping on irc (#ubuntu-mir on freenode) or documentation auditing as other good ways to start helping.

Posted in Coding, mir, Ubuntu | 2 Comments

Small Run Fab Services

For quite a while I’ve been just using protoboards, or trying toner transfer to make pcbs, with limited success.

A botched toner transfer attempt

A hackaday article (Why are you still making PCB’s?) turned me on to low cost, prototyping pcb runs. Cutting my own boards via toner transfer had lots of drawbacks:

  • I’d botch my transfer (as seen above), and have to clean the board and start over again. Chemicals are no fun either.
  • Drilling is tedious.
  • I never really got to the point where I’d say it was easy to do a one-sided board.
  • I would always route one-sided boards, as I never got good enough to want to try a 2 layer board.
  • There was no solder mask layer, so You’d get oxidation, and have to be very careful while soldering.
  • Adding silkscreen was just not worth the effort.

I seemed to remember trying to find small run services like this a while ago, but coming up short. I might be coming late to the party of small-run pcb fabs, but I was excited to find services like OSHpark are out there. They’ll cut you three 2-layer pcbs with all the fixins’ for $5/square inch! This is a much nicer board and probably at a cheaper cost than I am able to do myself.

Here’s the same board design (rerouted for 2layer) as the botched one above:

The same board design as above, uploaded into OSHpark

You can upload an Eagle BRD file directly, or submit the normal gerber files. Once uploaded, you can easily share the project on OSHpark. (this project’s download). You have to wait 12 days for the boards, but if I’m being honest with myself, this is a quicker turnaround time than my basement-fab could do! I’m sure I’ll be cutting my own boards way less in the future.

Posted in Hardware | Leave a comment

Bjarne on C++11

header image

I saw this keynote quite a while ago, and I still refer to it sometimes, even though its almost 3 years old now. Its a good whirlwind tour of the advances in C++11.

Posted in Coding | Leave a comment

More Usable Code By Avoiding Two Step Objects

header image

Two step initialization is harmful to the objects that you write because it obfuscates the dependencies of the object, and makes the object harder to use.

Harder to use

Consider a header and some usage code:

struct Monkey
    void set_banana(std::shared_ptr const& banana);
    void munch_banana();
    std::shared_ptr const& banana;

int main(int argc, char** argv)
    Monkey jim;

Now jim.munch_banana(); could be a valid line to call, but the reader of the interface isn’t really assured that it is if the writer wrote the object with two step initialization. If the implementation is:

Monkey::Monkey() :
void Monkey::set_banana(std::shared_ptr const& b)
    banana = b;
void Monkey::munch_banana()

Then calling jim.munch_banana(); would segfault! A more careful coder might have written:

void Monkey::munch_banana()
    if (banana)

This still is a problem though, as calling munch_banana() is silently doing nothing; and the caller can’t know that. If you tried to fix by writing:

void Monkey::munch_banana()
    if (banana)
        throw std::logic_error("monkey doesn't have a banana");

We’re at least to the point where we haven’t segfaulted and we’ve notified the caller that something has gone wrong…. But we’re still at the point where we’ve thrown an exception that the user has to recover from.

Obfuscated Dependencies

With the two-step object, you need more lines of code to initialize it, and you leave the object “vulnerable”.

auto monkey = std::make_unique();

If you notice, between lines 1 and 2, monkey isn’t really a constructed object. It’s in an indeterminate state! If monkey has to be passed around to an object that has a Banana to share, thats a recipe for a problem. Other objects don’t have a good way to know if this is a Monkey object, or if its a meta-Monkey object that can’t be used yet.

Can we do better?

Yes! By thinking about our object’s dependencies, we can avoid the situation altogether.
The truth is; Monkey really does depend on Banana..
If the class expresses this in its constructor, ala:

struct Monkey
    Monkey(std::shared_ptr const& banana);
    void set_banana(std::shared_ptr const& banana);
    void munch_banana();
    std::shared_ptr banana;

We make it clear when constructing that the Monkey needs a Banana. The coder interested in calling Monkey::munch_banana() is guaranteed that it’ll work. The code implementing Monkey::munch_banana() becomes the original, and simple:

void Monkey::munch_banana()

Furthermore, if we update the banana later via Monkey::set_banana(), we’re still in the clear. The only way the coder’s going to run into problems is if they explicitly set a nullptr as the argument, which is a pretty easy error to avoid, as you have to actively do something silly, instead of doing something reasonable, and getting a silly error.

Getting the dependencies of the object right sorts out a lot of interface problems and makes the object easier to use.

Posted in Coding | Leave a comment

Bad Metaphysics Costs Maintainability

header image

I find myself doing a lot of metaphysical thinking in my day to day work as a coder. Objects that are cohesive and are valid metaphysical analogues to common experiences make it much easier to read, understand, and fix existing code.

Taking an example:

struct ServiceQueue
    void place_customer_at_back();
    void service_front_customer();

This class maps well to a physical problem we encounter frequently in our day to day lives; customer service at a bank teller window, perhaps, or ordering a hamburger at fast food chain. Taking things to the realm of computers, ServiceQueue also maps to many computer problems pretty well as well. A packet arrives over the network, and we want to service the packet in a FIFO manner.

This class is cohesive and easily understood by someone new to the code because it maps well to a well understood concept; that of a Queue. By making use of the shared metaphysical concept of physical queueing, we introduce the new coder to the abstract queue that’s implemented in software. The new coder can understand and verify the interface and implementation quickly.

Now lets spice the interface up with a metaphysical error. Say that we have the above class, and we encounter an error condition that happens when the network becomes disconnected. One might be tempted to add a function like:

struct ServiceQueue
    void place_customer_at_back();
    void service_front_customer();
    void handle_network_disconnected();

The problem in adding this function is twofold; it makes the code harder to understand, and it makes writing a new object more difficult.

Rapid Understandibility

The first issues is that that analogue to a real life concept is diluted, and with enough dilution, will eventually be lost. This makes it more difficult to rapidly understand the role an object implementing the interface has.

I bet the coder that added “handle_network_disconnected” saw that a lot of the implementation where the error could be handled from was “conveniently” in the class implementing the interface, and punched “handle_network_disconnected” in. But did you catch the metaphysical error? ServiceQueue is no longer named properly, its become a different object. Its a ServerQueueThatCanBeDisconnected; and the analogy to the physical queue is weakened. It takes a bit more explaining to a new coder to explain what sort of interface ServiceQueue is. This additional explanation needed to the new coder makes it much more difficult to understand the object and the problem that is being solved. Consequently, its harder to maintain, and takes longer to debug, because of the added cost of understanding. 1

Alternative Implementations

With each error like this, it becomes a bit harder to write an implementation for the interface that solves a similar problem. ServiceQueue with “handle_network_disconnected” fits the network-packet problem, but its been made more difficult to use this interface with the myriad other problems (like the bank teller problem).

Now, in the practical world of software, we’re used to seeing this all the time. We can mentally handle one metaphysical error per interface quite easily. The actual problem comes in much worse scenarios, where there are multiple holes punched through the interface. Eventually, it can get to the point where the object really has no physical manifestation and the interface gets renamed to something ambiguous, like “ServiceManager”. At this point, the object has sluggish understandability, and is irreplaceable. We’ve found ourself with some difficult to maintain software!

It might take a bit of refactoring to get things right, but in the end, its worth it; both practically, and metaphysically.

This post originally appeared on kdubois.net, and is (c) Kevin DuBois 2015

Posted in Coding | Leave a comment

A few years of Mir TDD

asm header

We started the Mir project a few years ago guided around the principles in the book, Growing Object Oriented Software Guided by Tests. I recommend a read, especially if you’ve never been exposed to “Test-driven development”

Compared to other projects that I’ve worked on, I find that as a greenfield  TDD project Mir has really benefitted from the TDD process in terms of ease of development, and reliability. Just a few quick thoughts:

  • I’ve found the mir code to be ready to ship as soon as code lands. There’s very little going back and figuring out how the new feature has caused regressions in other parts of the code.
  • There’s much less debugging in the intial rounds of development, as you’ve already planned and written out tests for what you want the code to do.
  • It takes a bit more faith when you’re starting a new line of work that you’ll be able to get the code completed. Test-driven development forces more exploratory spikes (which tend to have exploratory interfaces), and then to revisit and methodically introduce refactorings and new interfaces that are clearer than the ropey interfaces seen in the ‘spike’ branches. That is, the interfaces that land tend to be the second-attempt interfaces that have been selected from a fuller understanding of the problem, and tend to be more coherent.
  • You end up with more modular, object-oriented code, because generally you’re writing a minimum of two implementations of any interface you’re working on (the production code, and the mock/stub)
  • The reviews tend to be less about whether things work, and more about the sensibility of the interfaces.
Posted in Coding, mir | Leave a comment

Mir Android-platform Multimonitor

My latest work on the mir android platform includes multimonitor support! It should work with slimport/mhl; Mir happily sits at an abstraction level above the details of mhl/slimport. This should be available in the next release (probably mir 0.13), or you can grab lp:mir now to start tinkering.

Posted in Coding, mir, Ubuntu | 2 Comments

SVG Hardware Drawer Labels

I recently made a set of SVG labels for my hardware small parts bin in Inkscape for the common Akro-Mills 10164 small parts organizer. Its sized to print the labels the correct size on a 11″x8.5″ sheet of paper (results may vary, so make sure to resize for whatever drawer and printer you have)


The Labels in action

I thought I’d share them here in SVG format, which should make it pretty easy for you to download and customize. (Eg, you could change the resistor color codes to your set of resistors, change the values, etc). If you do sink a lot of effort into adapting the file, please share-back (open source!) via the comments, and I’ll update the file so others can use it.

Drawer Labels

Drawer Labels

SVG file (copyright (c) 2015 Kevin DuBois, Licensed under CC BY-NC-SA)

Posted in Hardware, Open Source | Leave a comment

Saleae Logic 8 Review

Over the break, I got to play a bit with the Saleae Logic 8 logic analyzer. Its the mid-range model from Saleae, and it works with Ubuntu. I wrote about the predecessor to the Logic 8 a while back, before Linux support was around. I finally got to do a bit of tinkering with the new device, under Ubuntu Vivid.

logic 8

Logic 8

The device itself came packaged only in the carrying case that is provided. Inside the zippered carrying case was the Logic 8 itself, 2 4×2 headers with 6-inch leads, 16 logic probes, a micro-usb cable, a postcard directing you to the support site, and a poster of Buzz Aldrin in the Apollo cockpit.
The Logic 8 is made out of machined anodized aluminum and is only about 2×2 inches. It’s sturdy-feeling, and the only ports are the micro-usb to connect to the computer, and the 16 logic probe pins (8x ground+signal). There’s a blue LED on the top.


Package Contents

The test leads seem pretty good. I’m used to the J-hook type leads, and these have two pincers that come out. I’ve been able to get the leads into more places than I would have with a J-hook type logic probe.

Bonus Inspiration

Another really interesting feature is that this logic analyzer can do analog sampling. Each of the Logic 8 test leads can perform analog sampling. The device can sample faster if you’re only using one analog channel. One channel can sample at 10M samples/second, and running all 8 will sample at 2.5M samples/second. According to the literature, frequencies above the Nyquist frequency of the sample rate get filtered out before hitting the onboard ADC. If you’re anything like me, most of the my electronics tinkering doesnt require me to look at signals above this sampling rate, and I could see using the oscilloscope less and using the Logic 8 for some analog signals work too.

Underside of Logic 8

Underside of Logic 8

The Software:
The Logic 8 software is available (freeware, closed source) on the website and will simulate inputs if there’s no device connected, so you can get a pretty good feel for how the actual device will work. It was largely hassle-free, although I did have to unpack it in /opt because it wasn’t packaged. Overall, it was pretty intuitive to configure the sampling, set up triggers, and test my circuit. The look and feel of the software was much better than a lot of other electronics tools I’ve used.

Trying it out:
I was working on a pretty simple circuit that takes a sensor input and outputs to a single 7-segment. Its composed of a BCD-7segment decoder chip and an ATtiny13. (easy enough to program with the ubuntu packages ‘avrdude’ and ‘gcc-avr’).


Circuit Under Test (ATtiny13, a light sensor, and a BCD to 7 segment decoder)

Its not electrically isolated from the circuit, but I would expect that for the price point. Just make sure that you don’t have any ground loops between your computer and the circuit under test. I don’t typically build circuits that really need a earth-ground, so I don’t see that being much of an issue.

So, my first run, I connected it to the GPIO pins on the AVR and varied the voltage from 0-2.5V on the ADC pin.

ADC to 4bit digital

ADC to 4bit digital

Yay, my circuit (and avr program) was working.

I am pleased with the Logic 8, and am even more excited to have a hassle free way to measure logic and analog signals in Ubuntu!

Posted in Hardware, Reviews | Leave a comment