Planet Collabora

Learning

Platforms

• Import a set of keys
• Provide a resource grouping for the keys.
• Import any existing translations for these keys.
• Use the services platform to provide additional translations
• Export the resources in the desired languages.

• Will they use a single service to provide all their translations.
• Will they allow updates to the files in their revision control system and how those will be integrated.
• Will there be a verification step and if so who and how will that be performed. Especially important is the question of a reviewer understanding the translated language being integrated and how that is controlled.
• Will the project be paying for translations
• Will the project allow machine translations, if not can they be used as an initial hint (sometimes useful if the translators are weak in the "default" language

Implementing

Proof of concept

Something more useful

• Already internationalised but had limited language localisation 
• Did not directly use gettext 
• Had a code base I understood
• Could be modified reasonably easily.
• Might find the result useful rather than it being a purely academic exercise.

Conclusions

• Internationalisation has a number of complex areas
• Localisation to a specific locale is more than a mechanical process.
• The majority of platforms and services are oriented around textural language translation
• There is a concentration on the gettext mode of operation in many platforms
• Integration to any of these platforms requires both workflow and technical changes.
• At best tools to integrate existing resources into the selected platform need to be created
• Many project will require format conversion tools, necessitating additional developer time to create.
• The social issues within an open source project may require compromise on the workflow.
• The external platform may offer little benefits beyond a pretty user interface.
• External platforms introduce an external dependency unless the project is prepared and able to run its own platform instance.
• Real people are still required to do the translations and verify them.

Because I work on an awesome company I spent last week improving the Raspberry Pi ALSA driver.

A long standing issue was that the driver did not support memory-mapped I/O mode for audio stream transfers.

ALSA supports two transfers methods for PCM playback: Read/Write transfer where samples are written to the device using standard read and write functions and Direct Read/Write transfers where samples can be written directly to a mapped memory area and the driver is signaled once this has been done.

ALSA provides an API for both cases and each application using ALSA to access the audio device can choose which API to use. But since mmap was not supported by the bcm2835 driver, applications using the mmap API did not work on the Raspberry Pi.

To bypass hardware limitation such as the lack of mmap support, ALSA provides a set of PCM plug-ins that can be used to extend functionality and features of PCM devices.

These plug-ins are used by defining a custom /etc/asound.conf or .asoundrc and one of them is the mmap emulation plug-in (mmap_emul) which emulates mmap access using a set of read/write transfers. This plug-in was needed on the Raspberry Pi to allow applications using ALSA mmap API to work. But of course it introduces some latency and requires a custom configuration to enable it.

So, the best approach was to just add mmap support to the ALSA driver and get rid of the mmap emulation plug-in. Normally this is straightforward since the kernel allows memory areas to be mapped to user-space address space so applications can have direct access to device memory.

This was not the case on the Raspberry Pi since the PCM samples are processed by its VideoCore IVI GPU. The ARM11 CPU communicates with the VideoCore co-processor using a message passing interface (vchiq) which means that the CPU is not able to directly address the audio device hardware buffers and audio samples have to be sent to the device using vchiq messages.

Since hardware buffers can’t be directly mapped to user-space memory, an intermediate buffer is needed. This intermediate buffer is mapped to user-space so applications can store the audio samples there. Once user-space has finished writing the PCM samples they are pushed to VideoCore as vchiq messages.

Fortunately, the kernel ALSA subsystem provides a PCM indirect API which are a set of helper functions and a data structure to manage the intermediate and hardware buffers. It is really helpful so you don’t have to write all the buffer management.

So, after figuring out all of this I wrote a patch to add mmap support to the Raspberry Pi ALSA driver and send a pull request that also contained other improvements to the driver.

Since it has been merged on the Raspberry Pi kernel, this feature will be available on the next raspbian release but if you want to use it now you can do the following:

$ git clone git://github.com/raspberrypi/tools.git
$ git clone git://github.com/raspberrypi/linux.git
$ cd linux
$ git checkoub -b rpi-3.6.y origin/rpi-3.6.y
$ export ARCH=arm
$ export CROSS_COMPILE=../tools/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi-
$ make bcmrpi_defconfig
$ make prepare modules_prepare
$ make M=sound/arm
$ sudo cp sound/arm/snd-bcm2835.ko /media/rootfs/lib/modules/3.6.11+/kernel/sound/arm/
$ sudo rm /media/rootfs/etc/asound.conf

The last step is very important since using both a mmap capable ALSA driver and the PCM mmap emulation plug-in does not work.

I want to thank my employer Collabora for allowing me to work on this:

The Problem

The Idea

The Prototype

• Combined USB and Ethernet Jack on both boards was 30 mm tall 
• PCB width of 2mm
• underside components of 4mm
• clearance between boards of 2mm

Carrier designs for both the i.MX53 QSB and the i.MX6 SABRE Lite boards were created and fabricated at a professional 3D print shop which gave a high quality finish product and removed the perceived risk of relying on a personal 3D printer for a quantity of parts.

Deployed solution

• Needs its carrier fitting. It is currently just stuck to the subrack end plate.
• Needs its Ethernet cable replacing. The existing one has developed a fault post installation.
• Needs the USB hub supply separating from the device cable. The current arrangement lets the hub power the Pi which means you cannot power cycle it.
• Connect its switched supply separately to the USB hub/devices.

Shopping list

The final bill of materials (excluding labour and workshop costs) which might be useful to anyone hoping to build their own version.

Prices are in GBP currency converted where appropriate and include tax at 20% and delivery to Cambridge UK and were correct as of April 2013.

The purchasing was not optimised and for example around 20GBP could be saved just by ordering all the shapeways parts in one order.

Base subrack
Item	Supplier	Quantity	Line Price
Schroff 24563-194 subrack kit	Farnell	1	41.28
Schroff 24560-351 guide rails	Farnell	3	13.65
Schroff rack rear horizontal rail	Shapeways	2	100.00
1000mm length of 4mm threaded rod	B and Q	1	1.48
170mm x 431mm x 3mm Aluminium sheet	inspired steel	2	40.00
PSU mounting plate	Shapeways	1	35.42
PCB standoff	Shapeways	4	22.30
160mm Deep Modular PC supply	CCL	1	55.76
TP-Link TL-SF1016DS 16-Port 10/100Mbps-Switch	CCL	1	23.77
8 Channel 16A Relay Board Controlled Via Ethernet	Rapid	2	126.00
Raspberry Pi	Farnell	1	26.48
USB Serial converters	CCL	10	37.40
10 port strip style USB HUB	Ebay	1	7.00
Parts for custom Ethernet cables	RS	13	26.00
Parts for custom molex power cables (salvaged from scrap ATX PSU)	Workshop	11	11.00
33R 10W wirewound resistor for dummy load	RS	1	1.26
24pin ATX female connector pre-wired	Maplin	1	2.99
Akasa double sided thermal pad	Maplin	1	5.00
Small cable tie bases	Maplin	1	6.49
Miscellaneous cable, connectors, nylon standoffs, solder, heatshrink, zip ties, nuts, washers etc.	Workshop	1	20.00
Total for subrack			603.28

The carriers are similarly not optimally priced as over five GBP each can be saved by combining shipping on orders alone. Also the SSD drive selection was made some time ago and a newer model may be more suitable.

i.MX53 QSB carrier
Item	Supplier	Quantity	Line Price
i.MX53 QSB	Farnell	1	105.52
Intel 320 SSD 80G	CCL	1	111.83
Carrier board	Shapeways	1	30.00
combined sata data and power (15 to 20cm version)	EBay	1	5.00
Low profile right angle 5.5mm x 2.1mm barrel jack	EBay	1	0.25
Parts for 9pin serial cable extension	RS	1	5.00
Miscellaneous solder, heatshrink, nylon nuts, bolts and washers	Workshop	1	5.00
Total for carrier			262.60

i.MX6 SABRE Lite carrier
Item	Supplier	Quantity	Line Price
i.MX6 SABRE Lite	Farnell	1	128.06
Intel 320 SSD 80G	CCL	1	111.83
Carrier board	Shapeways	1	35.00
combined sata data and power (15 to 20cm version)	EBay	1	5.00
Low profile right angle 5.5mm x 2.1mm barrel jack	EBay	1	0.25
Parts for 9pin serial cable modification	RS	1	2.00
Miscellaneous solder, heatshrink, nylon nuts, bolts and washers	Workshop	1	5.00
Total for carrier			287.14

Conclusion

The solution works and in a 3U high 355mm deep subrack ten ARM development boards can be racked complete with local ethernet switching, power control and serial consoles.

The solution is neat and provides flexibility, density and reproducibility the "pile of stuff" solution failed to do.

For current prototype with nine filled slots the total cost was around 3000GBP or around 330GBP per slot which indicates a 100GBP per slot overhead over the "pile of stuff" solution. These figures omit the costs of the engineer and  workshop time, which are estimated at an additional 1500GBP. Therefore a completed rack, fully filled with i.MX6 carriers costs around 5000GBP

Density could be increased if boards with lower height requirements were used however above twelve units there issues with Ethernet switch, power switch and USB port availability become a factor. For Example the 16 port Ethernet switch requires a port for uplink, one for each relay board and one for the console server which leaves only 12 ports for systems.

Addressing the outstanding issues would result in a much more user friendly solution. As the existing unit is in full time use and downtime is not easily scheduled for all ten systems, the issues are not likely to be fixed on the prototype and would have to be solved on a new build.

That’s right — PulseAudio will be participating in the Google Summer of Code again this year! We had a great set of students and projects last year, and you’ve already seen some their work in the last release.

There are some more details on how to get involved on the mailing list. We’re looking forward to having another set of smart and enthusiastic new contributors this year!

p.s.: Mentors and students from organisations (GStreamer and BlueZ, for example), do feel free to get in touch with us if you have ideas for projects related to PulseAudio that overlap with those other projects.

So, in my earlier post, I mentioned that I’d been working on a library called xkbcommon. Since it’s got a massively misleading name (and renaming hasn’t been totally ruled out yet …), it’s probably worth an introductory post.

tl;dr: It loads XKB keymaps and can manage tricky things like modifier state for you.

tell me more!

At its core, xkbcommon is nothing to do, as you might think, with X11. It’s about two things: parsing and loading keymaps, and managing their ongoing state. State, in terms of keyboards, is the usual suspects — modifiers (e.g. Shift, Alt), multiple layouts (mostly for multiple languages), and LEDs. In general, you only want one person keeping a canonical copy of the state, and distributing it to its clients, as both the X server and Wayland do today. xkbcommon allows for this mode of operation, and is indeed how all current Wayland clients handle keyboard input.

One notable thing xkbcommon isn’t, is an input method. Anything more complex than ‘I press one key and get a symbol’, such as phonetic compound composition for CJK/Thai/etc (where you type out a word, which, when completed, becomes much fewer characters on screen) or menu-based selections as common in both Arabic and Mandarin (where you type out the beginnings of a word, and are then offered a selection of choices to complete), or even just the seemingly-straightforward compose key (e.g. right Alt + o + / → ø), are implemented internally to the toolkit, and don’t really use xkbcommon at all. Supporting the two (key-based vs. string-based) methods in the same protocol seems straightforward, but quickly becomes hugely unwieldy if you ever need to do anything weird like, say, process shortcuts. Anyway, if you want to find out more about input methods on Wayland, Michael Hasselmann has a very nice update about Maalit and ibus.

This makes life rather more simple for the keyboard-based protocols: all we have to do is tell xkbcommon every time someone presses (or releases) a key, and ask it which symbols resulted from that.

There are two methods of operation. The self-contained approach, suitable if you’re writing programs which back directly on to a terminal and have absolute full control over the entire keyboard, is used by most of our tests, such as interactive.c, which is a reasonably summary of how to implement one of these clients. Here, the same client manages the entire state, and never needs to deal with any external entities.

However, the most common method of operation is the one used by Wayland and X11, where a central server manages the state and informs the clients. Under this model, the clients never update the state implicitly through xkb_state_update_key(); they only ever use xkb_state_update_mask() in response to its master sending it a new and complete copy of the state.

ok — so how do I use it?

Firstly, create a context:

ctx = xkb_context_new(0);

which will be the base for all your xkbcommon operations. Secondly, we need to compile a keymap. If you have a named keymap you want to compile from (e.g. the user has specified ‘Icelandic Dvorak with Caps Lock mapped to Ctrl’), use:

keymap = xkb_keymap_new_from_names(ctx, rules, model, layout, variant, options);

On Linux, the rules and model are almost always ‘evdev’. Layout is usually the ISO two-character country (not language!) code, variant is specific to the layout, and options are global. In this case, we would use:

keymap = xkb_keymap_new_from_names(ctx, "evdev", "evdev", "is", "dvorak", "ctrl:nocaps");

A keymap is a static and immutable ruleset describing the translation between key events and the resulting output (e.g. if d is pressed while shift is held down, then output D). On top of the keymap, for every keyboard we use, we generate a new state object:

state = xkb_state_new(keymap);

which will track things like which keys are currently held down. Every time a key is pressed or released, we first get the symbols it produces:

sym = xkb_state_key_get_one_sym(state, keycode);

which returns a key symbol (listed in xkbcommon-keysyms.h, and identical to the X11 keysyms; xkb_keysym_to_utf8() may be used to translate this to a string)  generated by that keypress. For example, pressing the B key on Icelandic Dvorak with AltGr held down would return XKB_KEY_ssharp (i.e. ß). After we have got the symbol to be used, we then update the state object with the keypress. It is crucial the order of these two operations is not reversed! Anyhow, we update the state object like so for sole-control programs:

changed = xkb_state_update_key(state, keycode, XKB_KEY_DOWN);

or thusly for clients who get their master state from an external program, e.g. Wayland compositor:

changed = xkb_state_update_mask(state, mods_down, mods_latched, mods_locked, ...);

and we have now completed our key processing. Hurrah!

Note that you do not need any special cases anywhere: xkbcommon takes care of the mechanics of handling special keys under the hood for you. The one case where you need extended functionality is shortcut processing (e.g. capture Ctrl+P), but that’s a story for another day.

shouldn’t all this be in the documentation?

… yeah.

PS: Funny story: I was planning to explain in this footnote how I’d just picked Icelandic Dvorak for a laugh and no-one would make a layout that ridiculous. But no, it actually exists …

hi

Yeesh, it really has been a while, hasn’t it.

Last time we spoke, I was working on X11, and my blog was being served off a FreeBSD 4.3 machine (obviously named ‘amnesiac’), from the datacentre of an ISP who had long since forgotten which ex-employee’s Pentium II was sitting in that rack. Unfortunately I didn’t back it up, and no longer even have a copy of the RSS feed to import. Looking over the Wayback Machine copy though, I don’t think we’re missing much by losing that one. So here we are with WordPress, having blatantly ripped off Lucas’s theme.

Shortly after that machine died — early in 2012 — I finished up my last proper X11 project for a customer, went back to Australia for linux.conf.au and a holiday, and came back to start working on Wayland’s input subsystem (including xkbcommon, on which more in a future post). Working on Wayland has been really refreshing; not only did it feel like time for a change after nine years of working on X11, but diminishing returns meant that we were increasingly spending enormous amounts of time on X11 to achieve very marginal results.

The last major thing I did there was work with Chase Douglas (ex-Canonical) and Peter Hutterer (Red Hat) — though sadly due to timing, we almost entirely worked in relay, rather than together — on the XI2.3 multitouch protocol and implementation. I was quite proud to see it eventually make its way upstream, but having subsequently both tried to explain to others how it all hangs together, and watched Peter continue to fix corner-case after corner-case in its interactions with other parts of X11 input, it really solidified my view that X11 is a dead end for any new development.

stop whining and get on with it

A couple of months ago, in Canberra for linux.conf.au 2013, I gave a presentation about that very realisation.  Originally I thought of giving a kind of dispassionate comparison and explanation of the two, but it ended up becoming a fairly linear narrative of where X began, where it is now, and how Wayland organically developed from this. It’s a fairly well-worn line that Wayland is in many ways the culmination of the last ten years of X.Org development, but it really is true.

Part of that has not just been shedding the X11 cruft and getting the opportunity to start over ­­— though, given the state of the X11 protocol and its 28 common extensions, plus its codebase, that’s really no bad thing — but some radically different design decisions, down to the real fundamentals of the interfaces. Giving compositors a lot more context opens up a huge amount of possibilities for us (beginning with actually being able to activate a screensaver while a pop-up menu’s active …), and I’m really excited about the kinds of things we can do.

It’s been really interesting to see Wayland grow and develop into a fully-fledged window system. At Collabora, we’ve had Pekka, Louis-Francis, Fred and others working on Wayland support across the board: compositors, client toolkits/apps, and hardware enablement too. After the groundwork we’ve been doing, a lot of it is really starting to come to fruition and hopefully we’ll have some more shiny demos soon. Along the way, I managed to fulfill one of my goals I set a while ago, which was to get out of the bubble of only ever working on the server (since X clients were so uniformly unpleasant), and work throughout the stack. Over the past few months, I’ve been able to work on GStreamer, WebKit, Clutter, COGL, Mesa, and other EGL/GLES stacks, which has been really interesting.

where next?

With GTK+, Qt and Clutter all shipping Wayland support in their stable releases, the next big thing for me personally is watching the GNOME port progress. We’ve got a stable and solid core protocol and library now, but there are definitely some gaps to be filled in by having a real desktop environment ported, and certainly around input we’ve got a lot of things to support (e.g. touchpad support on par with xf86-input-synaptics, better mouse acceleration, support for synchronising keyboard repeat rates between clients, tablets, etc). But it’s quite exciting to see what people will be able to make of our work so far.

I’m back from this year’s GStreamer hackfest, which was fantastic as usual — an intersection of great minds, big challenges, flaky Wi-Fi and good food. Christian already did a generic summary, so I’ll be narrating from the GNonLin/GES/PiTiVi perspective. See the end of this blog post for a nice video retrospective.

Edward provided an initial patch to improve the behavior of timestamps and seeking in GNonLin, while Nicolas “Stormer” Dufresne fixed two bugs causing deadlocks. Nicolas spent a lot of time discussing with Wim Taymans, Edward Hervey, Sebastian Dröge and other hackfesters about the architecture of GNonLin in light of GStreamer 1.x. He also fixed looping for the Ogg demuxer in pull mode and, with some help from Mathieu “Forest Ranger” Duponchelle, fleshed out the design for a new tree data structure for GNonLin.

Mathieu the Moustached Avenger worked on implementing keyframes in GES, paving the way for him to create a user interface to animate any effect property in PiTiVi. That user interface will most likely depend on him working on the clutter timeline canvas, so I’m looking forward to improvements in that area.

Thibault “Keyboard Crusher” Saunier finished the implementation of GES Containers and clip groups, then worked on implementing — at long last — audio mixing in GES. This is an essential feature of multitrack audio/video editing, and I’m really happy to see that feature make its comeback for the next release of PiTiVi. This work will also depend on Mathieu’s keyframes UI. A proper reimplementation of video mixing remains to be done, however.

There are lots of outstanding things to solve in GNonLin and GES. Nicolas has a bunch of ideas for things to improve and redesign in GNonLin and I expect much collaboration between Thibault and him to optimize the entire stack for better reliability and performance (for example, adding caps filters to allow realtime downscaling of videos to improve preview performance, configurable downstream buffering for playback to avoid frame drops in CPU-intensive parts of a timeline, etc.). GNonLin and GES have much potential to allow us to be a lot smarter than before.

Personally, I spent most of my time testing, discussing and hacking on some new features for PiTiVi.

• I added a button in the timeline toolbar that toggles the “gapless mode” (automatic ripple edits), which makes your clips behave like magnets and prevents needing to re-arrange them manually all the time. The feature works and will be merged after a customary code review.
• I made some progress on the custom effects UI branch. Once it’s complete, you will be able to easily create custom user interfaces for effects that require it, simply by using a glade/gtkbuilder .ui file (or, if you prefer, a set of widgets from your own python module). Of course, for the majority of effects, our automatically generated user interfaces are still good enough, so we can keep using them and avoid unnecessary work.

(See my previous blog post for a situation report on where we stood with PiTiVi before the hackfest)

I also spent a bit of time setting up my film making gear and shooting various interesting moments of the hackfest. Here’s my montage, which will tell the story much better than a long blog post. Hope you’ll like it:

I would like to thank Collabora for allowing many GStreamer contributors to attend the hackfest, which I consider vital to the health of the GStreamer community. I was happy to meet again with many friends and help push the Free multimedia stack forward. Props to Christian Schaller and Alessandro Decina for organizing the whole thing, too!

Aside from Collabora and Fluendo sponsoring two of our dinners (thanks!), I would also like to thank you, PiTiVi supporters, for making it possible for me to spend some money to thank GStreamer contributors with some food and beer — maximum boost to the GStreamer community! Full disclosure: I used 84 euros worth of PiTiVi donations for that purpose.

Hi, KDE users. I think it is time we had an adult conversation about KMix and usability.

You see, in my last post, there was an awful lot of vitriol spewed about my heavy handed decision to use horizontal sliders. My personal belief is that vertical sliders have a tendency to induce vertigo in older users and ex-paratroopers. There is no way I can live my life with that kind of guilt on my conscious. Paratroopers serve an incredibly useful purpose in our military operations. I simply cannot allow these great ‘murricans to experience pain at my hands.

After much thought and discussion of usability with an awfully friendly bartender (and much tequila), I’ve decided to implement a compromise in KMix2:

Down and to the left means louder!

I hope you’re happy, because I certainly am.

I realize that this is a very controversial change, so I’ve created a kde pastebin entry to maintain this branch. We all know that KDE git is totally unreliable and the sysadmins are convinced that backups are not backups, so no sense in trying to stay there. The geniuses at Hacker News (who are never wrong or sensationalist) tried unsuccessfully to convince the sysadmins otherwise, so I must conclude that I have no reason to keep faith in them.

• UI redesign with nicer icons and layout.
• Has a cool logo
• It is a GNOME Project
• Sample video player of the GStreamer SDK
• Drag and drop media files into snappy
• Support for subtitle streams
• Ported to GStreamer 1.0
• Launcher from the desktop
• Works in Windows, OS X and Android
• Multi-screen Desktop full-screening
• Support for media queues
• Code style fixes for readibility
• Option to run without a User Interface
• More bug fixes than we are proud of :P

Time for a little report on recent improvements in Pitivi. Nothing earth-shattering to make you drool with envy; just a lot of fixes, cleanup and improvements to small details. Next week, we will be in Milan for the GStreamer hackfest, so I’ll make sure to give you a nice report on what we managed to accomplish there.

Here’s a list of fixes in Pitivi since my last blog post:

• Fixes for our automated UI tests, including interaction with the filechooser dialogs, the spinbutton widgets (see this bug report), the typing speed, etc.
• Fixes and cleanup for backend tests
• Enforce unicode in preset names, preventing a bug with non-ASCII chars are used in the name of a preset
• Allow presets with “/” in their name
• Fix drag and drop from the media library’s listview mode
• Prevent playing back clip previews in double (that was a subtle one, since windows were exactly on top of each other)
• Make the media library clip previewer work even when the application is in fullscreen mode
• Make effect properties work again
• Take into account project settings in the main window when loading a project
• Conform to the new version of the Freedesktop specification for thumbnail directories
• Make special characters show up correctly in the media library’s iconview mode, remove the ancient filename shortening code and rely on Pango instead.
• Properly handle clip URIs encoding, ensuring that we can find the thumbnails for all files. Also do last-minute checks for that encoding before computing thumbnail hashes.
• Avoid excessive work when searching clips in the media library, improving performance
• Handle special characters in the media library’s search entry
• Force calculating the toolbar height at the last minute to properly handle all screen setups in fullscreen
• Scale down effects thumbnails to fit better in the new listview arrangement
• Fix a race between clicks on the preview widget’s slider and position updates. When using it in the media library/file chooser, the slider would often “jump” back to its previous position instead of seeking. The new behavior is now smooth and reliable.
• Ensure the welcome dialog is initially centered on its parent
• Bring back the checkbox to enable/disable effects
• Initialize GES to prevent a segfault from occurring on some machines at startup
• Make rectangle selection work again in the media library’s iconview mode
• Make the “Restore from backup” dialog modal to the main window

New features:

• Automatically adjust the zoom when inserting to the end of the timeline
• When the viewer is undocked, provide a button to toggle fullscreen mode
• New icons for split, group/ungroup and align
• Specify the duration of missing/moved files when prompting the user about their new location
• Update effect categories, merge “Noise” and “Blur”, add a “Compositing” category, categorize new effects
• Automatically save the last used render directory
• Stop rendering when the user presses Escape
• Use symbolic icons everywhere where it makes sense (in the media library toolbar, property reset buttons, lists, etc.)
• Use the system’s default image viewer to preview images from the media library
• Update the preview widget slider on a more frequent basis, giving it a snappier feeling
• Automatically save and restore the main window’s position. This is especially useful when using detached utility windows.
• Hide the effects toolbar when nothing is selected
• Add a contextual help button in the render dialog to explain container formats
• Allow entering a frame number into the time widget

Architectural changes and cleanups:

• Clean up the build, prune useless files, simplify and centralize the list of dependencies
• Refactor dependency checks to be more reliable and provide a faster application startup
• GES Assets (implemented in GES and integrated in Pitivi), including the notion of GES Project among other things. This paves the way to many other improvements.
• A revised and simplified API has been implemented in GES and integrated in Pitivi. You can see this new API online in the GES API hierarchy documentation.

So yeah, that’s the summarized version… with refactoring and cleanup all over the place, there’s more than a hundred commits (excluding translations).

Stuff that still needs to be done (as always, we need your help here):

• Need to refactor the timeline UI code and the clip transformation UI
• Undo/redo
• Improving/expanding the UI tests, see the test suite wishlist
• Figure out how to better integrate the “welcome dialog”
• Figure out how to shave off the menu bar and how GTK AppMenu will work with accessibility technologies (and Dogtail)
• Improve the title editor UI
• Improve the timeline thumbnailer
• Reimplement the notion of grouping in GES
• Reimplement video compositing and audio mixing. Properly. In GES.
• Make a new keyframe UI that doesn’t suck. Integrate it for audio volume curves and to provide animatable effect properties.
• Fix… all the bugs! _o/
• Insert your own itch to scratch here

Ongoing work in my own/personal repository:

• Custom effect UIs
• New high-resolution icon (pictured above), new mimetypes
• Automatic rippling
• Resurrecting the codecs installer

Update: This isn't actually that much better than letting them access the private key, since nothing is stopping the user from running their own SSH agent, which can be run under strace. A better solution is in the works. Thanks Timo Juhani Lindfors and Bob Proulx for both pointing this out.

At work, we have a shared SSH key between the different people manning the support queue. So far, this has just been a file in a directory where everybody could read it and people would sudo to the support user and then run SSH.

This has bugged me a fair bit, since there was nothing stopping a person from making a copy of the key onto their laptop, except policy.

Thanks to a tip, I got around to implementing this and figured writing up how to do it would be useful.

First, you need a directory readable by root only, I use /var/local/support-ssh here. The other bits you need are a small sudo snippet and a profile.d script.

My sudo snippet looks like:

Defaults!/usr/bin/ssh-add env_keep += "SSH_AUTH_SOCK"
%support ALL=(root)  NOPASSWD: /usr/bin/ssh-add /var/local/support-ssh/id_rsa

Everybody in group support can run ssh-add as root.

The profile.d goes in /etc/profile.d/support.sh and looks like:

if [ -n "$(groups | grep -E "(^| )support( |$)")" ]; then
    export SSH_AUTH_ENV="$HOME/.ssh/agent-env"
    if [ -f "$SSH_AUTH_ENV" ]; then
        . "$SSH_AUTH_ENV"
    fi
    ssh-add -l >/dev/null 2>&1
    if [ $? = 2 ]; then
        mkdir -p "$HOME/.ssh"
        rm -f "$SSH_AUTH_ENV"
        ssh-agent > "$SSH_AUTH_ENV"
        . "$SSH_AUTH_ENV"
    fi
    sudo ssh-add /var/local/support-ssh/id_rsa
fi

The key is unavailable for the user in question because ssh-add is sgid and so runs with group ssh and the process is only debuggable for root. The only thing missing is there's no way to have the agent prompt to use a key and I would like it to die or at least unload keys when the last session for a user is closed, but that doesn't seem trivial to do.

KMix is KDE’s forgotten redheaded stepchild.

Humble beginnings

It is old, has been maintained my Christian Esken since early 2001, and has grown organically. Through no fault of Christian’s or anyone else’s, it is buggy, messy, and nobody else wants to help fix it, or at least has the constitution to do so.

Us redheads need to stick together.

At last year’s Randa, I started working on refactoring and rebuilding KMix from the ground up. Why should adjusting the volume in your desktop be so frustrating? It shouldn’t, thats why.

KMix is back with a new edition~

That is the prototype for the new KMix. The UI design has been shamelessly stolen from pavucontrol:

pavucontrol

As you can see, there is much work left to do. However, I feel that it is ready for others to hack on and test. This restructuring of KMix contains a *lot* of the original KMix code that has been contributed to over the years by over 142(!) people. The biggest committers have been Christian Esken (601), Colin Guthrie (130), and Laurent Montel (123). Mad props to those people and everyone else involved for their work and dedication.

When I started out on this endeavor, I aimed to fix a number of issues I had encountered before:

• Sometimes at startup, your volume would be all kinds of broken since the KDED module, Tray application, and a session startup script would all sometimes try to restore the volumes and sometimes it just wouldn’t.
• The GUI was completely rebuilt with every device change. Back in the early days of KMix, hot-pluggable audio devices wasn’t a major use case so it wasn’t included in the design.
• Since there is no one process that controls all the volume everywhere, that means lots and lots of backend libraries and their respective data structures loaded into many processes, such as plasma, the tray application, the KDED module, the tiny script at startup that restores your volumes.
• All these different points of control had to make sure they didn’t step on each others toes all the time.
• To control the volume over dbus, the tray application had to be running. There was no dbus autolaunch, and why would you want a GUI application to automatically launch and do weird things when you just want a small script to turn down your volume between the hours of 3 am and 6 am?
• pavucontrol had neat VU meters
• I’m just kinda okay at UI and UX design for end-users.

In response, I’ve come up with the following design:

• There exists a unique daemon on the session bus at org.kde.kmixd, which is managed via dbus autolaunch
• This unique daemon supports multiple backends being loaded at once, such as ALSA and PulseAudio (note: currently requires commenting out an if statement)
• Clients don’t need to worry about learning the oddities of ALSA or PulseAudio control since all interaction happens over the bus in a backend-agnostic manner. You are given a set of controls (such as your internal audio output, or the output of chrome’s flash plugin), a set of control groups (Output Devices, Recording Streams, etc), and a single interface to adjusting the master volume (which is whatever the user configures).
• Thanks to dbus autolaunch, you don’t have a daemon running in the background until the very instant during your session that volume control is needed. This helps to decrease startup time and overall resource usage.
• The UI is decoupled from the volume control itself, so others can easily create much better looking UIs in QML, Plasma, QtWidgets, or whatever other language that supports DBus.

All of this is in my kmix-improvements branch on KDE git’s kmix repository. I’ll reiterate: this is mostly just a pre-alpha. Don’t expect everything to work, though I have been using it on my desktops without significant issues. Feedback and contributions are welcome.

The 3.9 cycle in the Bluetooth subsystem was a way more calm than the previous ones. 49 non-merge patches were pushed upstream through bluetooth-next this time. The bulk of changes for this release comes from Johan Hedberg. Along with many fixes to the HCI Management code he also added support for 32 and 128 its UUID in the EIR data.

Other than that we only have fixes and clean ups from Andre Guedes, Andrei Emeltchenko, Gustavo Padovan, Rami Rosen and Szymon Janc.

One can always see all Bluetooth commits in the 3.9 with the following command line:

git shortlog –no-merges v3.8..v3.9-rc1 — net/bluetooth/ include/net/bluetooth/ drivers/bluetooth/

The 3.10 release is going to be a busy release for Bluetooth subsystem,so stay tuned!

Finding your way around

desktop

This contains the non frontend specific code that actually behaves like a browser. For example desktop/netsurf.c contains the three primary functions we outlined in the introduction. You will also find much of the function and data structures interfaces the frontend must provide. It is unlikely someone new to the project will need to change anything in here (there be dragons) but is an important set of routines.

utils

Here you will find the utility and compatibility interfaces, things like url handling, logging, user messages, base64 handling. These are utility interfaces that do not justify splitting out their functionality to a separate library but are useful everywhere. Changing an interface in here would likely result in a major refactor.
For example one quirk is the logging macro was created before varadic C preprocessor macros were universal so it must be called as LOG(("hello %s world", world_type)) e.g. with double brackets. Fixing this and perhaps improving the logging functionality would be "nice" but the changes would be massive and potentially conflict with ongoing work.

content

This contains all the core code to handle contents i.e. html, css, javascript, images. The handling includes retrieval of the resources from URI , correct caching of the received objects and managing the objects state. It should be explicitly stated that the content handlers are separate and use this core functionality. The actual content handlers to deal with object contents such as the routines to decode image files or render html are elsewhere.

image

This is where the content handlers for the various image types are kept. The majority of these image types (jpeg, png, webp, gif, bmp) use a standard library to perform the actual decode (libjpeg, libpng etc.). One special feature used by most image handlers is that of a decoded image cache which is distinct and separate from the content cache.
The decoded image cache manages decoding of the source images (the jpegs and pngs) into frontend specific "render" bitmaps. For example the gtk frontend keeps the decoded images as a cairo surface ready for immediate plotting.
The cache uses a demand based (when the browser actually displays the image) just in time strategy which has been carefully balanced, with real world input, to reduce the overhead of unnecessary image decoding and processing against memory usage for the render bitmaps.

css

The css content handlers provide for the processing of css source text and use the NetSurf libcss library to process into a bytecode suitable for applying style selection at render time.

javascript

The javascript handlers (strictly speaking this should be named the "script" directory as all types of script are handled here) provide basic functionality to bind a javascript engine to the rest of the browser, principally the Document Object Model (DOM) accessed with libdom. The only engine that currently has bindings is Spidermonkey from the Mozilla foundation.

render

This is the heart of the browser containing the content handler for html (and plain text). This handler deals with:

• Acquiring the html.
• Running the base parser as data arrives which generates the DOM and hence DOM events from which additional resource (stylesheets etc.) fetches are started.
• Deal with script loading
• Constructing the box model used for layout
• Performing the Layout and rendering of the document.

Because this module has so many jobs to do it has inevitably become very complex and involved, it is also the principle area of core development . Currently NetSurf lacks a dynamic renderer so changes made by scripts post document load event are not visible. This also has the side effect that the render is only started after the DOM has finished construction and all the resources on a page have completed their fetch which can lead to undesirable display latency.

Docs

Documentation about building and using NetSurf. If anyone wants a place to start improving NetSurf, this is it, it is very incomplete. It must be noted this is not where dynamically generated documentation is found. For the current Doxygen output the best place to look is the most recent build on the Continuous Integration system.

resources

These are runtime resources which are common to all frontends. To be strictly correct they may be the sources which get converted into runtime resources e.g. The FatMessages file which is teh message text for all frontends in all languages, this gets processed at build time into separate files ready.

!NetSurf

This is another resources directory and technically the resources for the riscos frontend. The naming and reliance on this directory are historical. To allow the RISC OS frontend to be run directly from the source directory and an inability of RISC OS to process symbolic links most common runtime resources end up in here and linked to from elsewhere.

test

These are some basic canned test programs and files, principally to test elements of the utils and perform specific exercise of various javascript components.

Getting started

git rebase --interactive

git pull --rebase

Playing nicely with others

• Demanding we fix or add a feature. At best we will ignore you...though merciless sarcasm is not an unusual response to this. Perhaps a polite suggestion to the users mailing list would get better response? This is simple case of misunderstanding the relationship with the developers, you got the software for free so demanding we spend our leisure time to change it for you is impolite, or at least that is how I see it (and I am British, we do polite to excess).
• Request write access to the git repository without a proven track record. We are fairly open to new developers once they have a track record but initially contributions should be via patch series on the mailing list we can feed to git-am. Eventually we may give you commit access to your own personal branch space and from there extend to the rest of the repository.
• Developing a feature without talking to the team first and then being upset when we reject it. This is especially aggravating for all concerned as effort is wasted all around. If you have a great idea for a feature talk to us first! And if we indicate in our typically polite way that it is not going to be accepted listen to us! Of course you are free to ignore us, just please do not be upset later on.
• Non-constructive criticism. What I refer to here is finding fault in our software without logging a bug or otherwise providing something to respond to. We try to provide the best software we can and by extension have a great deal of pride in our project. This antisocial behaviour helps no one but can have a large negative impact on developer productivity.

In conclusion

Resources

• Main website
• Development wiki
• Git Repositories
• Continuous Integration System
• Developers mailing list
• IRC
• Ohloh

Build environment

$ wget http://git.netsurf-browser.org/netsurf.git/plain/Docs/env.sh
$ less env.sh
$ source env.sh
$ ns-apt-get-install

External Libraries

Project Source and Internal Libraries

$ source env.sh
$ ns-clone
$ ns-make-libs install

Frontend selection

• amiga
  This frontend is for Amiga OS 4 on the power PC architecture and is pretty mature. It is integrated into the continuous integration (CI) system and has an active maintainer. Our toolchain repository can build a functional cross build environment, the target is ppc-amigaos.
• atari
  This frontend is for the m68k and m5475 (coldfire) architecture. It has a maintainer but is still fairly limited principally because of the target hardware platform. It is integrated into the continuous integration system. Our toolchain repository can build a functional cross build environment for both architectures.
• beos
  This frontend is for beos and the Haiku clone. It does have a maintainer although they are rarely active. It is little more than a proof of concept port and there is no support in the CI system because there is currently no way to run the jenkins slave client or to construct a viable cross build environment. This frontend is unusual in that it is the only one written in C++ 
• cocoa
  This frontend supports the cocoa, the windowing system of MacOS X, on both PPC (version 10.5) and X86 (10.6 or later). The port is usefully functional and is integrated into the CI system, built natively on Mac mini systems as a jenkins slave. The port is written in objective C and currently has no active maintainer. 
• framebuffer
  This frontend is different to the others in that it does not depend on a system toolkit and allows the browser to be run anywhere the projects internal libnsfb library can present a linear framebuffer. It is maintained and integrated into the CI system.
• gtk
  This frontend uses the gtk+ toolkit library and is probably the most heavily used frontend by the core developers.  The port is usefully functional and is integrated into the CI system, there is no official maintainer. 
• monkey
  This frontend is a debugging and test framework. It can be built with no additional library dependencies but has no meaningful user interface. It is maintained and integrated into the CI system.
• riscos
  This frontend is the oldest from which the browser evolved. The port is usefully functional and is integrated into the CI system. There is an official maintainer for this frontend although they are not active very often. Our toolchain repository can build a functional cross build environment for this target.
• windows
  This frontend would more accurately be called the win32 frontend as it specifically targets that Microsoft API. The port is functional but suffers from a lack of a maintainer. The port is integrated into the CI system and the toolchain repository can build a functional cross build environment for this target.

$ source env.sh
$ ns-make -C ${TARGET_WORKSPACE}/${NS_BROWSER} TARGET=gtk

$ source env.sh
$ cd ${TARGET_WORKSPACE}/${NS_BROWSER}
$ ns-make
$ ./nsgtk

I read a few good articles in English about the latest elections in Italy, but they all seemed a bit unclear about what can actually happen and what cannot happen.

I hope this post can be easy to understand, not too boring and not too imprecise (I’m trying to simplify a few things and I didn’t study law).

A brief introduction

Italy is a parliamentary republic. The parliament is formed by two separate houses, the chamber of deputies and the senate. The two houses have the same powers to make laws and to pass votes of confidence for the government.
The cabinet is usually formed by members of the parliament, but this is not a requirement. The prime minister is not particularly powerful, for instance the prime minister cannot dismiss ministers or call for new elections.
The president of Italy is the head of state. The president is mainly a figurehead with limited powers, but becomes very important when it’s time to form a new government or to dissolve the parliament.
The president is elected by a joint session of the two houses of the parliament plus 58 local representatives for a 7-year term.

How is the parliament elected?

The current electoral law, disliked by almost everybody, was used for the first time in 2006 and was designed to make it difficult for the left to get a stable majority. Parties can form coalitions or stand on their own.
For the lower house, the coalition or party with the most votes automatically gets 55% of the seats. The rest of the seats are assigned to the other coalitions or parties on a proportional basis.
The senate is elected in a similar way, but on a regional basis (Italy is formed by 20 regions). This means that the party or coalition that gets most of the votes in a region gets 55% of the seats assigned to that region. It means that, at a national level, it’s possible that nobody will have a majority.

What are the main parties/coalitions in Italy?

The left is formed mainly by the Democratic Party (a center-left social democratic party) and by Left Ecology Freedom (a communist-ish/green party).
The centre is a mix of Christian and economically liberal parties. Its leader is Mario Monti, the current technocrat prime minister.
The right is formed by Silvio Berlusconi‘s People of Freedom and by the Northern League (they want more independence for the North of Italy and they are a bit populist and racist).
The new entry at the latest elections was Beppe Grillo‘s Five Star Movement. Their policies are a mix of environmentalism, anti-corruption and euroscepticism. While most of their goals are laudable, they are very populist with huge holes in their policies; basically it’s not clear where they could get the money for any of their policies. While they claim to value direct democracy, it’s Beppe Grillo who actually completely controls the party, even if he was not a candidate at the elections.

Why isn’t Beppe Grillo in the parliament?

Beppe Grillo says he is just the spokesperson of his party. Moreover, the Five Star Movement is against electing people that were found guilty of any crime in the past and Beppe Grillo was found guilty of manslaughter for a car accident in which three passengers died.

Who won the elections?

Nobody. The left has a majority in the lower house, but no current coalition has a majority in the senate.

Who voted for the 5 Star Movement?

Apparently one third of their voters used to vote for the left, one third for the right and one third didn’t vote in the past.

What is going to happen now?

The new parliament’s term will start in a couple of weeks. At that point the two houses need to vote for their presidents/speakers. Then the Italian president will hold meetings with the various political leaders and try to find a prime minister that has good chances of creating a cabinet that could pass a confidence vote by both houses of the parliament. This is the problem as there is no majority at the moment.

Is a broader coalition possible?

In theory yes. Any coalition will have to include the left because they control the lower house.

• A coalition of the left and the centre is what most people expected before the elections, but Monti didn’t get as many votes as expected, so this coalition would not have a majority in the senate.
• A coalition of the left and the 5 Star Movement would have a majority, but Beppe Grillo doesn’t want to form alliances with anybody. The 5 stars are against traditional politics and want a deep renovation of the Italian political class; if they decided to form an alliance with a traditional party they would lose a lot of their voters.
• A coalition of the left and the right is possible too, but unlikely. The current technocrat government was, after all, a coalition of left, centre and right, but Berlusconi decided to stop supporting it, so why should he be trusted again? Moreover, I think that a coalition of left and right would disgust a lot of their voters.

Is a minority government possible?

It would be very unstable but yes, it would be possible to have a minority government formed by the left and, maybe, the centre with external support by the 5 stars. The problem is that this cabinet would still need to pass a vote of confidence in the lower house (easy) and in the senate (not so easy as the 5 stars don’t want to vote for it).

But the 5 star senators could just abstain, right?

No. Abstentions in the senate count as no, so the government would not get the parliament’s confidence.

But the 5 star senators could just leave the senate during the confidence vote!

No. Votes in the senate are only valid if the majority of senators are present. The right would not have enough votes to block the confidence vote, but they could just leave before the vote, making the vote invalid.

Can’t you just vote again?

Usually the president, when it’s clear that there is no chance to form a cabinet, calls for elections, but this time it’s not possible.
The authors of our constitution were worried that a president could dissolve the parliament just before the end of the presidential term in the hope of getting a more favourable parliament that would elect the current president for another term.
The term of the current president will end in a few months, so he cannot dissolve the parliament now.

How about another technocrat government?

It would be possible (and it would be very different from the current one!) but it would be very difficult to get the left and the 5 stars to agree on much.

Could the new parliament elect another president that would then dissolve the parliament?

Yes, but finding an agreement to make this happen is going to be complicated and take time. In the meantime, Italy won’t have a stable government (the current Monti government will be in charge until a new government is found, but with very limited powers).

So, what is going to happen?

Good question. I have no idea.

Two recent announcements have been made about how it's viewed that people should interact with each other. Both, in my opinion, are misguided.

Firstly, Yahoo's chief executive, Marissa Mayer has announced that she's banning staff from remote working.  The idea behind this announcement is simple - that "some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings". This is absolutely spot on, but the next sentence in the leaked internal memo is more problematic:  "Speed and quality are often sacrificed when we work from home".
Don't get me wrong, working remotely has some special challenges, but they are by no means insurmountable. There's lots of tips for people working remotely which will turn into a future blog post at some point (I'm running an internal training about how to do it in a couple of weeks), but three simple rules are stay connected, set a routine and take care of yourself.

The second decision is one by Ubuntu to move Ubuntu Developer Summits to a purely online meeting, ditching the physical meeting. This misses the point of conferences. If we simply wanted to listen to talks and presentations, why meet up at all? Webcasts have been around for the last 20 years, and yet conferences still exist. The most important part of a conference isn't the talks, it's the "hallway track" - it's the ability for people to meet up, chat and socialise. Be this an impromptu meeting in the corridor, or over a few nice beers. Without this component, why schedule a time at all? Simply publish a list of talks over the coming 3 months, and anyone can pick the best time for them to attend.

At Collabora, many of our engineers work remotely. One of the perks we offer is the ability to attend conferences, and to "touch base" and visit and work from one of the offices. It is important to recognise the importance of collaboration physically  and it shouldn't be discounted the way Ubuntu has done. But it should not be seen as a silver bullet to an organisation, like Yahoo seem to be implying. Both extremes are wrong, and a balance must be struck to ensure the best outcome for productivity and innovation.

(Title from an iconic 80s song)

Hey everyone,

I have just released a new version of libnice, the NAT traversal library.

Version 0.1.4 has a few bug fixes but the major changes are the addition of an SDP parsing and generation API.

You can now more easily generate your credentials and candidates and parse them with a single API call, making it much easier to exchange candidates and establish a successful connection.

Also, I have added three examples to the examples/ subdirectoy from the libnice source tree. Those examples should help anyone learn how to use libnice and what to do in order to establish a successful connection.

The first example, simple-example.c will create a new agent, and gather its candidates and print out a single line to paste on the peer. It uses the signals to asynchronously wait for events and continue the code execution.

The second example, threaded-example.c, will run the mainloop on the main thread and do everything else sequentially in another thread, waiting for signals to release the libnice thread to continue processing.

The final example, sdp-example.c, is based on the threaded example but uses the new SDP generate/parsing API to generate the candidates and credentials line to exchange between the two instances. It will base64 the SDP to make it all fit into a single line, making it easier to exchange the SDP between clients without having to parse the multi-line SDP in the example, keeping it small and concise.

I hope you will find this release useful, let me know if you have any comments.

You can get the latest version here and the documentation has been updated here.

KaKaRoTo

The BlueZ project recently made a new major release, BlueZ version 5. This release brings tons of new features and improvements, however it is also accompanied by a significant  API change that makes it non-backwards compatible. BlueZ has changed to use the standard D-Bus Properties and Object Manager infrastructure, simplifying the handling of D-Bus interfaces and notifications. In addition to matching to D-Bus standards, the API of some of our interfaces also had to change, either to support new features and use cases or to optimize the API usage.

Another sensible change is related to the kernel requirements of BlueZ 5.0. BlueZ developers have recently added the Bluetooth Management (MGMT) Interface to the Linux Kernel, which significantly improves the Bluetooth experience on Linux. Among other things, you now get fine control of the HCI commands and events we send and receive to/from the Bluetooth device. In the past, this control was split between userspace and the kernel, creating synchronization problems. Now, it is handled solely by the MGMT interface in an internal queue inside the kernel. This change makes the bluetoothd daemon wake up a lot less often, saving more CPU and power for your system. A nice side-effect of those changes is that we could also get rid of blocking operations in the bluetoothd daemon when talking with Bluetooth devices.

As the MGMT interface is the only one to support the new Bluetooth Low Energy devices, BlueZ developers decided to drop support for the old interface once MGMT was completed. As a result, you need to be running Linux Kernel 3.4 or newer to use BlueZ 5.

While BlueZ developers felt the API change was necessary for this new BlueZ release, they understand that API breaks are painful for everyone. Therefore, in BlueZ 5 they introduced the notion of API versioning. For example, let’s say that today BlueZ supports “org.bluez.Device1” and “org.bluez.AgentManager1” interfaces, among others. The “1“ would refer to version 1 of the API. If for some reason we need to upgrade the Device API a new interface, “org.bluez.Device2”, could be created while still supporting the “org.bluez.Device1” interface. The two interfaces will therefore be supported simultaneously, giving you time to port your software to the new API instead of seeing things breaking overnight.

To help you with the migration to BlueZ 5, we released an extensive guide introducing the new APIs.

If you need help to bring your product to the future of Bluetooth on Linux, Collabora is available to assist you with your adoption of BlueZ 5. We can also help you on any commercial support, development or training around BlueZ, come talk to us.

165 Bluetooth commits are present in the latest release of the Linux Kernel, the 3.8 one. The majority of the commits were related to the Bluetooth High Speed feature, they are from Andrei Emeltchenko and Mat Martineau, most of the
code needed for the High Speed is now in mainline, however this feature is still disabled and considered as experimental.

Another important set of patches is from Johan Hedberg to enable support for Low Energy single mode Bluetooth radios. Those are now well supported by the Linux Kernel.

A new printk modifier, %pMR, was introduced to help print Bluetooth devices addresses, which are stored in the little endian order. The modifier was actually introduced in 3.7, however we could only make the changes in the Bluetooth subsystem for 3.8. Then we were able to remove the old and racy batostr() function from the subsystem. This was work of Andrei Emeltchenko.

Also, the ongoing work of split the L2CAP code into the Core an Socket parts gained a few more improvements by Gustavo Padovan. More work is expected to come in the next releases.

The SCO socket interface gained support for the Defer Setup feature, which is already present in the L2CAP and RFCOMM sockets interface. Defer Setup allows the kernel to ask the userspace if it wants to accept an incoming connection or not. Sometimes we don’t even want connections to be established, so stopping them at the CONNECTING state is of great help.

Apart from that we added support for 5 new Bluetooth devices that do not report themselves correctly as Bluetooth devices or need some firmware to be loaded. And as usual we had a lot of small changes, comprehending fixes, clean ups and small improvements.

Interested in GStreamer, PiTiVi, GES? Meet us in Milan at the end of March for the 2013 GStreamer hackfest! As you can see in this picture from last year’s hackfest, it’s tons of fun for everybody:

No, really! It’s an incredibly productive and motivating event to participate in.

One of the major items we would like to accomplish is to fix GNonLin as much as possible. As you know, the GStreamer 1.x series is a major departure from the 7 years old 0.10 series’ design, and GNonLin needs to be rethought for the new world order. The current state of GNonLin makes it impossible for nonlinear audio/video editing applications to behave properly in GStreamer 1.x. This affects Pitivi, Jokosher, Novacut, and perhaps others.

If you want to work on PiTiVi’s UI at the hackfest, you are of course welcome to do so. I always have nice projects to play with, such as the need for a new keyframe UI, fixing undo/redo, improving the performance of the thumbnail system, helping Pēteris with the GStreamer waveforms library implementation, or porting the timeline and viewer canvases to Clutter.