I got a new toy. It’s a WASD keyboard with Cherry MX Clear switches. The picture doesn’t do it justice; maybe I should’ve gotten a new camera instead… I guess it’ll have to wait.

Mechanical-switch keyboards are pricey, but since I spend more than 2000 hours a year in front of a keyboard, it’s not a bad investment. Or so I’m telling myself. Anyway, it’s a big step up from the rubber dome one I’ve been using for the past couple of years. The key travel is longer, and it’s nice to have proper tactile feedback. Since the Clear switches have stiff springs, I can also rest my fingers on the keys when daydreamingthinking. It has anti-slip pads underneath, so it stays put, and it doesn’t bounce or rattle at all.

Until our last move, I clung to an older, clicky keyboard (I don’t remember which brand — I thought it was Key Tronic, but I’ve a hard time finding any clicky keyboards of theirs at the moment), worried that the future held rubber dome and chiclets only — but today, there are lots of options if you look around. I guess we have mostly gamers and aficionados to thank for that. So thank you, gamers and aficionados.

I did plenty of research beforehand, but WASD finally drew me in with this little detail: They have some very well thought-out editable layout templates for SodipodiInkscape. Good taste in software there.

README.SUSE

So it seems you installed the discourse package that we provide for openSUSE/SUSE.

Preparing PostgreSQL

$ zypper in postgresql-server postgresql-server

$ su - postgres

$ createuser -P discourse

$ createdb -O discourse discourse

Add the required postgresql extensions to the DB. We extract those at build time from the migrations. If you run migrations with a normal postgresql user, you can not add extensions during the migrations. That’s why we add them here.

For Hackweek 11 I thought it’d be fun to learn something about creating Android apps. The basic training is pretty straightforward, and the auto-completion (and auto-just-about-everything-else) in Android Studio is excellent. So having created a “hello world” app, and having learned something about activities and application lifecycle, I figured it was time to create something else. Something fun, but something I could reasonably complete in a few days. Given that Android devices are essentially just high res handheld screens with a bit of phone hardware tacked on, it seemed a crime not to write an app that draws something pretty.

The openSUSE desktop wallpaper, with its happy little Geeko sitting on a vine, combined with all the green growing stuff outside my house (it’s spring here) made me wonder if I couldn’t grow a little vine jungle on my phone, with many happy Geekos inhabiting it.

Android has OpenGL ES, so thinking that might be the way to go I went through the relevant lesson, and was surprised to see nothing on the screen where there should have been a triangle. Turns out the view is wrong in the sample code. I also realised I’d probably have to be generating triangle strips from curvy lines, then animating them, and the brain cells I have that were once devoted to this sort of graphical trickery are so covered in rust that I decided I’d probably be better off fiddling around with beziers on a canvas.

So, I created an app with a SurfaceView and a rendering thread which draws one vine after another, up from the bottom of the screen. Depending on Math.random() it extends a branch out to one side, or the other, or both, and might draw a Geeko sitting on the bottom most branch. Originally the thread lifecycle was tied to the Activity (started in onResume(), killed in onPause()), but this causes problems when you blank the screen while the app is running. So I simplified the implementation by tying the thread lifecycle to Surface create/destroy, at the probable expense of continuing to chew battery if you blank the screen while the app is active.

Then I realised that it would make much more sense to implement this as live wallpaper, rather than as a separate app, because then I’d see it running any time I used my phone. Turns out this simplified the implementation further. Goodbye annoying thread logic and lifecycle problems (although I did keep the previous source just in case). Here’s a screenshot:

The final source is on github, and I’ve put up a release build APK too in case anyone would like to try it out – assuming of course that you trust me not to have built a malicious binary, trust github to host it, and trust SSL to deliver it safely

Enjoy!

Update 2014-10-27: The Geeko Live Wallpaper is now up on the Google Play store, although for some reason the “Live Wallpaper” category wasn’t available, so it’s in “Personalization” until (hopefully) someone in support gets back to me and tells me what I’m missing to get it into the right category.

Updated Update: Someone in support got back to me. “Live Wallpaper” can’t be selected as a category in the developer console, rather you have to wait for Google’s algorithms to detect that the app is live wallpaper and recategorize it automatically.

Change your directory to /sys/devices/system/cpu/intel_pstate

system:/sys/devices/system/cpu/intel_pstate # l
total 0
drwxr-xr-x  2 root root    0 Oct 21 18:45 ./
drwxr-xr-x 14 root root    0 Oct 21 18:45 ../
-rw-r--r--  1 root root 4096 Oct 21 18:45 max_perf_pct
-rw-r--r--  1 root root 4096 Oct 21 18:45 min_perf_pct
-rw-r--r--  1 root root 4096 Oct 21 18:45 no_turbo

# cat max_perf_pct
100

# cat min_perf_pct
32

One of the things that has always been a bit of a struggle in Firefox for Android is getting reliable video decoding for H264. For a couple of years, we’ve been shipping an implementation that went through great heroics in order to use libstagefright directly. While it does work fine in many cases, we consistently get reports of videos not playing, not displayed correctly, or just crashing.

In Android 4.1, Google added the MediaCodec class to the SDK. This provides a blessed interface to the underlying libstagefright API, so presumably it will be far more reliable. This summer, my intern Martin McDonough worked on adding a decoding backend in Firefox for Android that uses this class. I expected him to be able to get something that sort of worked by the end of the internship, but he totally shocked me by having video on the screen inside of two weeks. This included some time spent modifying our JNI bindings generator to work against the Android SDK. You can view Martin’s intern presentation on Air Mozilla.

While the API for MediaCodec seems relatively straightforward, there are several details you need to get right or the whole thing falls apart. Martin constantly ran into problems where it would throw IllegalStateException for seemingly no valid reason. There was no error message or other explanation in the exception. This made development pretty frustrating, but he fought through it. It looks like Google has improved both the documentation and the error handling in the API as of Lollipop, so that’s good to see.

As Martin wrapped up his internship he was working on handling the video frames as output by the decoder. Ideally you would get some kind of sane YUV variation, but this often is not the case. Qualcomm devices frequently output in their own proprietary format, OMX_QCOM_COLOR_FormatYUV420PackedSemiPlanar64x32Tile2m8ka. You’ll notice this doesn’t even appear in the list of possibilities according to MediaCodecInfo.CodecCapabilities. It does, however, appear in the OMX headers, along with a handful of other proprietary formats. Great, so Android has this mostly-nice class to decode video, but you can’t do anything with the output? Yeah. Kinda. It turns out we actually have code to handle this format for B2G, because we run on QC hardware there, so this specific case had a possible solution. But maybe there is a better way?

I know from my work on supporting Flash on Android that we use a SurfaceTexture there to render video layers from the plugin. It worked really well most of the time. We can use that with MediaCodec too. With this output path we don’t ever see the raw data; it goes straight into the Surface attached to the SurfaceTexture. You can then composite it with OpenGL and the crazy format conversions are done by the GPU. Pretty nice! I think handling all the different YUV conversions would’ve been a huge source of pain, so I was happy to eliminate that entire class of bugs. I imagine the GPU conversions are probably faster, too.

There is one problem with this. Sometimes we need to do something with the video other than composite it onto the screen with OpenGL. One common usage is to draw the video into a canvas (either 2D or WebGL). Now we have a problem, because the only way to get stuff out of the SurfaceTexture (and the attached Surface) is to draw it with OpenGL. Initially, my plan to handle this was to ask the compositor to draw this single SurfaceTexture separately into a temporary FBO, read it back, and give me those bits. It worked, but boy was it ugly. There has to be a better way, right? There is, but it’s still not great. SurfaceTexture, as of Jelly Bean, allows you to attach and detach a GL context. Once attached, the updateTexImage() call updates whatever texture you attached. Detaching frees that texture, and makes the SurfaceTexture able to be attached to another texture (or GL context). My idea was to only attach the compositor to the SurfaceTexture while it was drawing it, and detach after. This would leave the SurfaceTexture able to be consumed by another GL context/texture. For doing the readback, we just attach to a context created specifically for this purpose on the main thread, blit the texture to a FBO, read the pixels, detach. Performance is not great, as glReadPixels() always seems to be slow on mobile GPUs, but it works. And it doesn’t involve IPC to the compositor. I had to resort to a little hack to make some of this work well, though. Right now there is no way to create a SurfaceTexture in an initially detached state. You must always pass a texture in the constructor, so I pass 0 and then immediately call detachFromGLContext(). Pretty crappy, but it should be relatively safe. I filed an Android bug to request a no-arg constructor for SurfaceTexture more than two years ago, but nothing has happened. I’m not sure why Google even allows people to file stuff, honestly.

tl;dr: Video decoding should be much better in Firefox for Android as of today’s Nightly if you are on Jelly Bean or higher. Please give it a try, especially if you’ve had problems in the past. Also, file bugs if you have issues!