Mir Device Showcase!

Here’s a video of Mir powering a few different GPUs:

  • Nexus 10 (ARM Mali T-604 GPU)
  • Nexus 4 (Qualcomm Adreno 320 GPU)
  • Nexus 7 (2012) (Nvidia Tegra 3)
  • Galaxy Nexus (PowerVR)

This is a pretty big milestone, as we’re now in a position where Mir works well with 4 big Android gpu vendors.

Enjoy!

The only disclaimer on the video is that some of the code hasn’t trickled to the images yet, and the tablet support is still a work in progress. Onwards and upwards!

Posted in Hardware, mir, Ubuntu | 2 Comments

Friendly Mir Links

Just a friendly reminder, but Mir is open! Here are some useful links.

Documentation

We’ve put effort into sharing as much as possible and lowering the knowledge-barrier to entry for the project. We want you to understand how your pixels will be painted under Mir. Here’s some good links:

Mir documention: http://unity.ubuntu.com/mir/
This is all generated right from the trunk code (lp:mir’s doc/ folder)
We also generate api documentation on same site: http://unity.ubuntu.com/mir/annotated.html

Code

The code is all available on launchpad: lp:mir
The reviews are all done on out in the open: active reviews
Our continuous integration is on jenkins like the rest of the Ubuntu projects: https://jenkins.qa.ubuntu.com/job/mir-ci/
Lastly there are no secret branches or anything like that anymore. We’re operating fully in the open! :)

Coordination and Planning

We do all of our coordination surrounding the code on freenode’s #ubuntu-mir channel. Since this is an Ubuntu channel, its logged. Here’s an example: #ubuntu-mir log You’ll see in the logs that we really do our updates, coordination and planning all on this channel.

We have our blueprints out in the open too. You can see our upcoming plans and the upcoming work items that are slated.

We’ve got a mailing list on launchpad too! Join up and stay abreast of all the latest email chains.

Posted in Coding, mir, Open Source, Ubuntu | 2 Comments

Mir and Android GPU’s

With Ubuntu Touch, (and mir/unity next) we’re foraying into a whole new world of android drivers. Given the community’s bad memories from the past about graphics, let’s clear up what’s going on, and how we’ll steer clear of the murky waters of new driver support and get rock-solid Ubuntu on mobile platforms.

Android Driver Components and their Openness

First let’s talk about openness. Driver ecosystems tend to be complex, and android is no exception. To get a driver to work on android, the gpu vendors provide:

  1.  a kernel module
    The kernel module must be GPL compatible and this part of the driver is always open. This part of the driver has the responsibility of controlling the gpu hardware, and its main responisibility is to manage the incoming command buffers and the outgoing color buffers.
  2. libhardware implementations from android HAL.
    These libraries are the glue that takes care of some basic operations the userspace system has to do, like composite a bunch of buffers, post to the framebuffer, or get a color buffer for the graphics driver to use. These libraries (called gralloc, hwc, fb, among others) are sometimes open, and sometimes closed.
  3. an OpenGLES and EGL userspace library
    These are the parts that program the instructions for the GPU, and they are the ‘meat and potatoes’ of what the vendors provide. Unfortunately this code is closed source, as many people already know. Just because they are closed source though doesn’t mean we don’t have some idea of what’s going on in them though. They rely on the open source parts and have been picked apart pretty well by various reverse-engineering projects (like freedreno)

All the closed parts of the driver system are used via headers that are Apache license or  Khronos license. These headers are API’s that change slowly, and do so in a (relatively) non-chaotic manner controlled by Google or the Khronos groups. These APIs are very distinct from DRM/gbm/etc that we see on ‘the free stack’

The drivers are not 100% open, and its not 100% closed either.  Without the closed source binaries, you can’t use the core GLES functionality that you want, but enough parts of the system are open that you can infer what big parts of the system are doing. You can also have an open source ecosystem like Mir or android built around them because we interface using open headers.

As far as openness goes, its a grey area; its acceptable to call them blob drivers though :)

Stability/Performance/Power

We have a lot of bad memories about things not working. I remember fighting all the time with my compiz drivers back in the days of AIGLX and the like. Luckily when we’re working on Mir and phones, we’ve remembered all this pain and have a reasonable way that we’ll jump onto the new driver platform without any wailing or gnashing of teeth.

The biggest advantage we have with the mobile drivers is that they are based around a fixed industry API that has proven itself on hundreds of millions of devices. We’re not reinventing the wheel here! We’re not heading out on our own to invent our own HAL layer, and we do not have to brow-beat gpu vendors into supporting a new API.

With this, we pick up a lot of the goodness that comes with out-of-the box Android drivers, like great power management, performance, and stability. Mir can use android drivers as they come from the driver vendor, and we’re using them in a well-known way.

Drivers and hardware support are the foundation of a well performing, amazing computing experience. With Mir and Ubuntu Next, we’re not building our house upon sand, we’re building it upon rock!

A Sneak Peek

Here’s a sneak peek of Mir (from lp:mir). This is a demo of just mir and (essentially) the Qt client that the Ubuntu Touch interface uses; this is not using Unity Next. The device is a Nexus4 with and Adreno320 gpu.

Posted in Coding, mir, Open Source, Ubuntu | 7 Comments

Mir and Android FAQ

There’s been some murmurs and uncertainty about Mir and Ubuntu Touch support, so here’s a quick FAQ.

Does mir support android drivers?

Yes! We put great care into our platform abstraction so that when you run on mesa desktop drivers, you use our mesa/gbm platform, but when you run mir inside of an Ubuntu Touch phone/tablet, you use the android platform to get full OpenGLES acceleration.

What sort of acceleration do you provide with android drivers?

Full acceleration! More specifically, this means that entire path, from client render to framebuffer post, is OpenGLES accelerated and there is no-copy of the color buffers. This gives mir clients and Unity Next the performance it needs to succeed.

Android uses java. Does this mean mir uses java?

Heavens no. Mir has no java inside. We are proudly a C++11 project (and we actually use the great new stl additions that come in C++11, like lambdas, smart pointers, and the like)

Do I need android tools (eg, the android SDK or NDK) to develop mir on Ubuntu Touch?

Nope! All of our dependencies and build tools come from debian packages wtihin Ubuntu. We use the gcc arm toolchains (and cross toolchains) available in the ubuntu repositories. The adb tool (from package android-tools-adb) is useful for development, but not necessary.

What devices do you run on?

We are focusing on the nexus line at first, but we should be able to enable all devices, regardless of gpu vendor. (we’re aiming for ICS drivers and newer).  We keep a list of the devices we are focusing on here.

How does Mir support android drivers?

We use the binaries available directly from the android gpu vendors as they are. Android driver developers have invested [b,m]illions of dollars to make sure that android drivers run well on android, and mir does not throw this effort away by trying to reinvent the wheel. Android drivers use 1) the android kernel, 2) the bionic libc and 3) the userspace driver libraries. We use this exact combination in mir so that Mir can be just as solid as the Android display system.

Does this mean mir uses bionic libc?

In short, no. The mesa/GBM platform goes nowhere near bionic libc. On the android platform, we carefully and cleverly tinker with the linker so that the Android drivers use bionic, but the mir code and libraries use the normal gnu libc. Mir code uses gnu libc that we all know and love, but we let the android drivers use libc they know and love (bionic).

Did you consider using some of the android components (eg surfaceflinger) instead of writing Mir?

Yes we did. We found that:

  1. Surfaceflinger is very tied to the android system and would take a large amount of porting work to run inside of Ubuntu Touch.
  2. Surfaceflinger is currently focused on a simplistic z-order based compositing, we needed something that can support the full Unity experience you expect on a desktop. The complex “launchers” you use in android are not part of surfaceflinger.
  3. Finally, adapting surfaceflinger to use mesa/gbm drivers is a ton of work (and probably not possible). We love the free stack drivers and need to support them for the desktop.

Do Mir clients care what platform (Android or mesa/GBM) they are running on?

Nope! A mir client will be able to run on a mesa/gbm platform or an android platform. We took great care to make sure that the clients are agnostic to the underlying OpenGLES driver model. There is no recompilation and no platform detection needed.

How can I find out more?

Easiest way is to pop on #ubuntu-mir (freenode) and ask me (kdub) a question. Mir is entirely open source so reading through the documentation and code there is also an option.

Posted in Coding, mir, Open Source, Ubuntu | 7 Comments

Why we Make

This is a great talk about the fundamentally human aspect of making. Our race’s advantage in the universe isn’t the sharpest claws or thickest skin, its the ability to make, bend, and discover. This video is an cool little anecdote from Adam Savage of mythbusters of how he embraced his inner maker:

People make things in all different sorts of ways, from a 4 year old making arts and crafts to a professional engineer building the Space Station (or a world class operating system :) ). Its fundamental to being human, so get out there and create!

Posted in Hardware, Random | Leave a comment

C++11 first impressions

I’ve been embroiling myself in C++11 lately, and have to say I like this version of the C++ language a lot more than I’ve liked previous versions. A lot of the rough edges have been cleaned up and there’s some powerful new features as well.

The Upsides:

  1. They did a good job at pulling in a lot of the ‘less controversial’ parts of boost into the STL. Its just easier when you don’t have to juggle STL and boost, and can just use the STL in a lot of cases.
  2. Spawning a thread is now pretty easy and clean. Thread synchronization mechanisms are very easy to access and clean as well.
  3. “smart pointers” are growing on me. My C background made me a bit skeptical at first about this memory management model, but I’m beginning to trust them more, and can see some benefits.
  4. Move semantics are a pretty cool idea for managing memory. It’ll be interesting to see how that pans out in the greater software ecosystem.

The Neutrals:

There are a lot of points about the new standard that I feel pretty neutrally about. They’re nice to have, but I might not use them that often, like new STL data types or STL regular expressions support.

The downsides:

  1. Although I’ve come to an understanding with them, r-value vs l-value references are somewhat obscure to understand. I wouldn’t like to be a new programmer learning about this in Computer Science 102 again!
  2. Compiler support is still coming along, slowly but surely. GCC 4.7 has most of the critical features, but coding with all of the C++11 feature set is still not supported, and (worse yet) I wouldn’t consider the STL support “fully trusted”.
  3. All the other objects to C++. :) C++ isn’t short of its detractors. I’m not interested in a compare-contrast with other languages in this post, just sharing my findings about C++11

Overall, I think that C++11 is a good improvement/evolution of the C++ standard. It’ll be interesting to see how code in the wild looks under c++11!

Posted in Uncategorized | 1 Comment

Wiring Stereos in a Chrysler Crossfire

This is just a story about how I replaced my stereo. Please do not take this advice for your situation. Incorrect wiring can cause all sorts of damage or fires or trouble. Have a professional install your stereo!

I have a 2007 Chrysler Crossfire roadster, and it had a terrible stock radio. It has ten tiny buttons crammed together to control the stations, which you can’t figure out by feel alone. Randomly, it can take like 5 seconds to respond to a button press. It also sometimes goes into “AM AS” and “FM AS” mode, which as far as I can tell, just means “ignore button presses until you turn the radio on and off”. Very useful. Plus, it doesn’t have a USB port, it doesn’t have an AUX input port, and it doesn’t have any bluetooth capabilities. In California, there’s a law that says you can’t hold your phone in your hand if you’re talking in the car. (Being a manual transmission car, I couldn’t hold the phone in my hand anyways) Also being in California, the traffic is pretty terrible, and being able to talk on the phone with people would alleviate commute frustration.

The Finished Stereo Install

All that being said, I decided to buy a Clarion CZ501 and replace the stock unit. It has a built in microphone, so I don’t have to route a new microphone wire through my upholstery for calls. It also has bluetooth profiles for phone calls, and bluetooth A2DP/AVCR profiles. This means that your phone can play music over bluetooth, and when you press the “next” button on the receiver, your phone will advance a track. Everything I wanted, plus the standard AM/FM radio. You can expand this unit with a satellite adapter, a HD radio adapter, or an external microphone to use instead of the internal microphone if you need these. ( I don’t particularly need these features )

Here’s what I had to buy at the end of the day:

  1. Clarion CZ501 radio receiver ($132)
  2. Scosche VM01B harness (for German car audio, I think) ($5)
  3. A bunch of wire caps for splicing wires together ($5/100 ct)
  4. A special DIN tool for removing German DIN’s. ($5)
  5. A 40-EU10 euro female antenna to motorola male antenna ($10)

I think if you buy a different radio unit than the Clarion, it might need a euro car to motorola female adapter. The Clarion needs a male adapter though, so thats what I bought. I don’t have a ‘system’, so I didn’t have to worry about hooking up an amp or anything. I don’t have the trunk space for anything else in this tiny car!

I inserted the DIN tool to the two flat slots at the bottom of the radio, and heard a ‘click!’. Then I just pulled the radio out, and disconnected everything at the back.

Next, I spliced the VM01B harness to the harness provided in the radio kit. I wired it thusly:

VM01B color Clarion color
black black
blue blue

Next, I just plugged the antenna adapter to the back of the clarion, and the harnesses up as well. I inserted

Everything seems to be working well. Bluetooth syncs to my Android Nexus S well, and I can make calls, and stream music. If I leave my Bluetooth on in my phone, the stereo will auto-sync when I sit down in my car. If I push forward or backwards on the stereo, my phone advances the track. AM/FM works, and I can listen to my favorite stations. My car is a ragtop, and gets a lot of road noise. Even at that, everyone (except my mother) can hear me very well in the car while I’m driving down the highway. Sound quality for music is good enough for my needs!

Posted in Random, Reviews | Leave a comment

The Black Triangle

Stuart Langridge on Planet Ubuntu posted about this story a while back, and its a something that’s happened to me a lot of times over my career.

The Black Triangle

The tl;dr is that a complex, extremely flexible system, well built system often takes a long time to put together, and the first fruit of the labor is often something seemingly simple to do from the perspective of someone else. However, the complex underpinnings of the well designed system allow the project to grow by leaps and bounds once that first black triangle is shown on the screen! That ‘black triangle’ one of the coolest parts of being an engineer.

(Oh, and, being a graphics guy, I definitely have had a lot of black triangles appear on the screen…. I slightly prefer the multicolored ones though… :) )

Posted in Coding, Open Source, Random, Uncategorized | Leave a comment

C++ 11 tip of the day

If you’re working with code using C++11 ‘s use of the <thread> library, and you get this error at runtime:

 terminate called after throwing an instance of 'std::system_error'
  what():  Operation not permitted
zsh: abort      ./main
 

That means you forgot to tell g++ to link to the pthread library when you compiled. Add the flag

 -lpthread 

to your g++ command string, and you should be set to go.

I’ve run into this error a few times already, and I haven’t found a good google search that answers it, so I decided to write this one. Hope it absolves a few head-scratchers out there….

Posted in Coding, Open Source | 1 Comment

Irssi OSD notifications

I wanted irssi to ping me using Ubuntu/Gnome’s on screen notification system, but didn’t want to dig into irssi’s code… what is one to do?

Cobble scripts together of course! Here’s how I got it done:

  1. Download this irssi plugin: fnotify.pl
    This script will update a text file  (~/.irssi/fnotify) with a new line every time you are pinged
  2. Put fnotify.pl in ~/.irssi/scripts
  3. autorun this script by executing:
    ln -s ~/.irssi/scripts/fnotify.pl ~/.irssi/scripts/autorun/fnotify.pl
  4. start irssi, and run:
    /hilight -nick {your_nick}
    /save
  5. When someone pings you, check the ~/.irssi/fnotify file for that ping, it should be there
  6. Download my script below (call it lastline_notify) and run it like this:
    ./lastline_notify ~/.irssi/fnotify & disown
#!/usr/bin/python
import os
import sys
import pyinotify
import pynotify

if (len(sys.argv) != 2):
	print "usage: lastline_notify "
	sys.exit(-1)
filename = sys.argv[1]

class PTmp(pyinotify.ProcessEvent):
	def process_IN_MODIFY(self, event):
		print "Create: %s " % os.path.join(event.path, event.name)

		#get the last line in file
		with open(filename) as myfile:
			msg_text =  (list(myfile)[-1])

		msg = pynotify.Notification("Irssi Notification:", msg_text)
		msg.show()

wm = pyinotify.WatchManager()
mask = pyinotify.IN_MODIFY
notifier = pyinotify.Notifier(wm, PTmp())
wdd = wm.add_watch(filename, mask, rec=True)
pynotify.init("Irssi")

while True:
	try:
		notifier.process_events()
		if notifier.check_events():
			notifier.read_events()
	except KeyboardInterrupt:
		notifier.stop()
		break

Viola! You now get a message in the upper right hand corner like if someone were to ping you on empathy. There might be a better way to do this, but it works for me! Both channel pings and queries should get a notification. This script runs as a daemon, so you shouldnt have to worry about it gobbling up CPU.

Posted in Open Source, Random, Ubuntu | Leave a comment