November 12th, 2015

wayland and libkscreen benchmarks

So, first of all, this is all very much work-in-progress and highly experimental. It’s related to the work on screen management which I’ve outlined in an earlier article.

libkscreen wayland benchmark data

I ran a few benchmarks across our wayland stack, especially measuring interprocess communication performance when switching from X11 (or, in fact XCB and XRandR) to wayland. I haven’t done a highly scientific setup, just ran the same code with different backends to see how long it takes to receive information about screens connected, their modes, etc..
I also ran the numbers when loading the libkscreen backend in-process, more on that later.


The spreadsheet shows three data columns, in vertical blocks per backend the results for 4-5 individual runs and their mean values. One column for the default out-of-process mode, one with loading the backend in process and one showing the speedup between in- and out-of-process of the same backend.
The lower part contains some cross referencing of the mean values to compare different setups.
All values are nano seconds.


My results show a speedup of between 2 and 2.5 times when querying screen information on X11 and on wayland, wayland being much faster here.
The qscreen and xrandr backends perform pretty similar, they’re both going through XCB. That checks out. The difference between wayland and xrandr/qscreen can then be attributed to either the wayland protocol or its implementation in KWayland being much faster than the corresponding XCB implementations.

But, here’s the kicker…

in- vs. out-of-process

The main overhead, as it turns out, is libkscreen loading the backend plugins out-of-process. That means that it starts a dbus-autolaunched backend process and then passes data over DBus between the libkscreen front-end API and the backend plugin. It’s done that way to shield the client API (for example the plasma shell process or systemsettings) from unsafe calls into X11, as it encapsulates some crash-prone code in the XRandR backend. When using the wayland backend, this is not necessary, as we’re using KWayland, which is much safer.
I went ahead and instrumented libkscreen in a way that these backends are being loaded in process, which avoids most of the overhead. This change has an even more dramatic influence on performance: on X11, the speedup is 1.6x – 2x, on wayland loading the backend in-process makes it run 10 times faster. Of course, these speedups are complementary, so combined, querying screen information on wayland can be done about 20 times faster.

While this change from out-of-process to in-process backends introduces a bit more complexity in the library, it has a couple of other advantages additional to the performance gains. In-process means that debugging is much easier. If there are crashes, we do not hide them anymore, but identify and fix them. It also makes development more worthwhile, since it’s much easier to debug and test the backends and frontend API together. It also means that we can load backend plugins at the same time.

I’ve uploaded the benchmark data here. Before merging this, I’ll have to iron out some more wrinkles and have the code reviewed, so it’s not quite ready for prime-time yet.

November 6th, 2015

Screen management in Wayland

One of the bigger things that is in the works in Plasma’s Wayland support is screen management. In most cases, that is reasonably easy, there’s one screen and it has a certain resolution and refresh rate set. For mobile devices, this is almost always good enough. Only once we starting thinking about convergence and using the same codebase on different devices, we need to be able to configure the screens used for rendering. Especially on desktops and laptops, where we often find multi-monitor setups or connected projectors is where the user should be able to decide a bunch of things, relative position of the screens, resolution (“mode”) for each, etc.. Another thing that we haven’t touched yet is scaling of the rendering per display, which becomes increasingly important with a wider range of displays connected, just imagine a 4K laptop running north of 300 pixels per inch (PPI) connected to a projector which throws 1024*768 pixels on a wall sized 4x3m.

The Wayland protocol currently does not provide a mechanism for setting up the screen, or tell us about displays that are not used for rendering, either because they’re disabled, or have just been connected, but not enabled “automatically” (yet). For most applications, that doesn’t matter, they’re just fine with knowing about the rendering screens and some details about those, which is provided by the wl_output interface. For screen management, this interface is insufficient, though, since it lacks a few things, EDID information, enabled/disabled flags and also ways to set the mode, scaling, rotation and position. This makes clearly recognizing display and setting them up harder than necessary, and thus error-prone. Let’s look at the background, first, however.

Setting up X11

On the hardware side, this has been a complete mess in the past. One problem is X11’s asynchronous nature. The XRandR extension that is used for this basically works by throwing a bunch of calls to the X server (“use this mode”, “position display there”) and then seeing what sticks to the wall. The problem is that we never really know what happened, there’s no well-defined “OK, this works” result, and we also don’t know when the whole procedure is done. The result is a flicker-fest and the desktop trying to catch up with what X11 made of the xrandr calls. It can also be an unpleasant experience, when a display gets connected, used for rendering, then the shell finds out about it, expanding the desktop to it, and then everything is resized again because there’s a predefined configuration for this. These kind of race conditions are very hard to fix due to the number of components involved in the process, and the lack of proper notification semantics around it.

X11 has the nasty habit of interacting with hardware directly, rather than through well-defined and modern kernel interfaces. On the kernel side, this has been fixed. We now have atomic mode setting, which allows us to check whether changes can be applied (through the DRM_MODE_ATOMIC_TEST_ONLY flag), and apply them all at once, or in portions that are known to not screw up, lock the user out, or are simply invalid in context with each other.
For the user, getting this right across the whole stack means quicker reconfiguration of the hardware and only minimal flickering when switching screen setups. We won’t be able to completely prevent the flickering on most displays, as that is simply how the hardware works, but we will be able to make it a lot less jarring. The compositor now being the one that calls the DRM subsystem on the user side, we can coordinate these things well with visual effects, so we’ll be able to make the user experience while re-configuring displays a bit smoother as well.

Atomic mode setting, DRM and kernel

From the kernel side, this needed quite radical changes, which have now landed throughout the DRM subsystem. The result is a kernel interface and helper library that allows interacting with the kernel using semantics that allow tighter control of the processes, better error prevention and handling and more modern power management semantics. Switching off the screen can now be done from the compositor, for example — this allows us to fix those cases where the display is black, but still has its backlight on, or where the display is off, but used for rendering (in which case you get huge blind spots in your user interface).
Daniel Vetter’s (part 1, part 2) provides an excellent overview over history, present and future of atomic mode setting on the kernel side. Pertaining is that a reasonably recent Linux kernel with working DRM drivers now provides all that we need to fix this problem on the user side. X11 is still in the way of a completely smooth solution, though.

Screen setup in Plasma

In Plasma, the screens can be set up using the Display configuration module in system settings. This module is internally called “KScreen”. KScreen provides a visual interface to position displays, set resolution, etc.. It’s backed by a daemon that can apply a configuration on login – useful stuff, but ultimately bound by the limits across the underlying software stack (X11, kernel, drivers, etc.).

KScreen is backed by libkscreen, a library that we ship with Plasma. libkscreen offers an API that allows to list displays, their properties, including disabled displays. libkscreen is driven by out-of-process running backends, commonly used is the “xrandr” backend, which talks to the X Server over the XRandR extension. libkscreen has other backends, notably a read-only QScreen backend a “fake” backend used for unit tests. A native Wayland backend is work in progress (you can find it in the libkscreen[sebas/wayland] branch.)

libkscreen been developed for the purpose of screen configuration, but we have also started using it for the Plasma shell. QScreen, the natural starting point of this was not up to the task yet, missing some functionality. In Qt 5.6, Aleix Pol has now landed the necessary missing functionality, so we can move the Plasma shell back onto QScreen entirely. QScreen is backed by the XCB Qt platform plugin (QPA). One problem in Plasma has been that we got acknowledged of changes through different code paths, which made it hard to set up the desktop, position panels, etc. In a Wayland session, this has to happen in a much more coordinated way, with clearly defined semantics when the screen setup changes, and as little of those changes as necessary.
KScreen should concentrate on doing what it’s good at: screen configuration. For X11 kscreen uses its xrandr backend, no changes there. In Plasma shell’s startup, we will be able to remove libkscreen and rely purely on QScreen directly as soon as we can depend on Qt 5.6, so that probably puts us into the time-frame of Q2 next year. For read-only access on wayland, we can use the libkscreen QScreen backend for now, it comes with some limitations around multi-screen, but these will be ironed by spring next year. The QScreen backend is actually used to start Plasma Mobile’s on kwin_wayland. For configuration, QScreen is not an option, however — it’s simply not its purpose and shouldn’t be.

In the Wayland protocol itself, there are no such semantics yet. Screen configuration has, so far, been outside of the scope of the agreed-upon wayland protocols. If we don’t run on top of an X server, who’s doing the actual hardware setup? Our answer is: KWin, the compositor.


KWin plays a more central role in a Wayland world. For rendering and compositing of windows, it interacts with the hardware. Since it already initializes hardware when it starts a Wayland server, it makes a lot of sense to put screen configuration also exactly there. This means that we will configure KWin at runtime through an interface that is designed around semantics of atomic mode setting, and KWin picks a suitable configuration for connected displays. KWin saves the configuration, applies it on startup or when a display gets switched off, connected or disconnected, and only then tells the workspace shell and the apps to use it. This design makes a lot of sense, since it is KWin that ultimately knows of all the constraints related to dynamic display configuration, and it can make concert how the hardware is used and how its changes are presented to the applications and workspace.

KWayland and unit testing

Much of Kwin/Wayland’s functionality is implemented in a library called KWayland. KWayland wraps the wayland protocol with a Qt-style API for wayland clients and servers, offers threaded connection and type-safety on top of the basic C implementation of libwayland.
KWayland provides a library that allows to run wayland servers, or just specific parts of it with very little code. The KWayland server classes allow us to test a great deal of the functionality in unittests, since we can run the unit tests on a “live” wayland server. Naturally, this is used a lot in kwayland’s own autotests. In the libkscreen wayland backend’s tests, we’re loading different configuration scenarios from json definitions, so we can not only test whether the library works in principle, but really test against live servers, so we cover a much larger part of the stack in our tests. This helps us a lot to make sure that the code works in the first place, but also helps us catch problems easily as soon as they arise. The good unit test coverage also allows much swifter development as a bonus.

Output management wayland interface design

The output management wayland protocol that we have implemented provides two things:

  • It lists connected output hardware and all of their properties, EDID, modes, physical size, and runtime information such as currently used mode, whether this output device is currently enabled for rendering, etc.
  • It provides an interface to change settings such as mode, rotation, scaling, position, for hardware and to apply them atomically

This works as follows:

  1. The server announces that the global interfaces for OutputManagement and a list of OutputDevices is available
  2. The configuration client (e.g. the Display Settings) requests the list of output devices and uses them to show the screen setup visually
  3. The user changes some settings and hits “apply”, the client requests an OutputConfiguration object from the OutputManagement global
  4. The configuration object is created on the server specifically for the client, it’s not exposed in the server API at this point.
  5. The client receives the config object and calls setters with new settings for position, mode, rotation, etc.
  6. The server buffers these changes in the per-client configuration object
  7. The client is done changing settings and asks the server to apply them
  8. The compositor now receives a sealed configuration object, tests and applies the new settings, for example through the DRM kernel interface
  9. The compositor updates the global list of OutputDevices and changes its setup, then it signals the client failure or success back through the configuration object

The output management protocol, client- and server-side library, unit tests and documentation are quite a hefty beast, combined they come in at ca. 4700 lines of code. The API impact, however, has been kept quite low and easy to understand. The atomic semantics are reflected in the API, and it encourages to do the right thing, both for the client configuring the screens, and the compositor, which is responsible for applying the setup.

Next steps

I am currently working on a libkscreen module for screen configuration under wayland, that implements atomic mode setting semantics in libkscreen. It uses a new wayland protocol which Martin Gräßlin and I have been working on in the past months. This protocol lands with the upcoming Plasma 5.5, the libkscreen module may or may not make the cut, this also depends on if we get the necessary bits finished in KWin and its DRM backend. That said, we’re getting really close to closing the last gaps in the stack.

On the compositor side, we can now connect the OutputManagement changes, for example in the DRM backend and implement the OutputDevices interface on top of real hardware.

September 11th, 2015

Wall drawing

Sol Lewitt's wall drawing at Stedelijk Museum Amsterdam

Sol Lewitt’s wall drawing at Stedelijk Museum Amsterdam

A few weeks ago, I visited the Stedelijk Museum in Amsterdam for an exhibition of Henry Matisse’s works. What stuck is not a painting or collage by Matisse, but a wall drawing by Sol Lewitt. I took a photo with my phone and have since then used it as wallpaper for it, and it works well, colors are nicely toned, everything provides enough contrast, and I like how it looks on a screen.

Yesterday, when I needed a break from hacking on Plasma’s Wayland integration, I remade the photo into vector art to use it as wallpaper. You can download the result here (the wallpaper package has versions for all resolutions, including phone and landscape versions, you can just unzip the package into /usr/share/wallpapers).

August 5th, 2015

Plasma Mobile IRC Meeting

Tomorrow, on Thursday at 12:00 CEST (10:00 UTC), we will hold a Plasma Mobile IRC meeting in #plasma on Freenode. We want to discuss some workflow and project management bits, and how we can effectively shape our workflows with the tools available. It’s also a great way to say “hi!” and get involved, or just lurk around if you’re interested in what’s going on.

Be there or be square!

July 28th, 2015

PSA: Plasma Mobile forums have moved

For a short while, the Plasma Mobile forums were hosted outside of the official KDE Forums. In our quest to put everything under KDE governance, we have now moved the Plasma Mobile forums under KDE’s forums as well. Enjoy the new Plasma Mobile forums.

As a few users had already registered on the “old” forums, this means a smallish interruption as the threads could not be quickly moved to the new forums. We’re sorry for that inconvenience and would like to ask everyone to move to the new forums.

Thanks for your patience and sorry again for the hassle involved with that.

July 25th, 2015

Embracing Mobile

At Blue Systems, we have been working on making Plasma shine for a while now. We’ve contributed much to the KDE Frameworks 5 and Plasma 5 projects, and helping with the transition to Qt5. Much of this work has been involving porting, stabilizing and improving existing code. With the new architecture in place, we’ve also worked on new topics, such as Plasma on non-desktop (and non-laptop) devices.

Plasma Mobile on an LG Nexus 5

Plasma Mobile on an LG Nexus 5

This work is coming to fruition now, and we feel that it has reached a point where we want to present it to a more general public. Today we unveil the Plasma Mobile project. Its aim is to offer a Free (as in Freedom), user-friendly, privacy-enabling and customizable platform for mobile devices. Plasma Mobile runs on top of Linux, uses Wayland for rendering graphics and offers a device-specific user interface using the KDE Frameworks and Plasma library and tooling. Plasma Mobile is under development, and not usable by end users now. Missing functionality and stability problems are normal in this phase of development and will be ironed out. Plasma Mobile provides basic functionality and an opportunity for developers to jump in now and shape the mobile platform, and how we use our mobile devices.

As is necessary with development on mobile devices, we’ve not stopped at providing source code that “can be made to work”, rather we’re doing a reference implementation of Plasma Mobile that can be used by those who would like to build a product based on Plasma Mobile on their platform. The reference implementation is based on Kubuntu, which we chose because there is a lot of expertise in our team with Kubuntu, and at Blue Systems we already have continuous builds and package creation in place. Much of the last year was spent getting the hardware to work, and getting our code to boot on a phone. With pride, we’re now announcing the general availability of this project for public contribution. In order to make clear that this is not an in-house project, we have moved the project assets to KDE infrastructure and put under Free software licenses (GPL and LGPL according to KDE’s licensing policies). Plasma Mobile’s reference implementation runs on an LG Nexus 5 smartphone, using an Android kernel, Ubuntu user space and provides an integrated Plasma user interface on top of all that. We also have an x86 version, running on an ExoPC, which can be useful for testing.

Plasma Mobile uses the Wayland display protocol to render the user interface. KWin, Plasma’s window manager and compositor plays a central role. For apps that do not support Wayland, we provide X11 support through the XWayland compatibility layer.

Plasma Mobile is a truly converged user interface. More than 90% of its code is shared with the traditional desktop user interface. The mobile workspace is implemented in the form of a shell or workspace suitable for mobile phones. The shell provides an app launcher, a quick settings panel and a task switcher. Other functionality, such as a dialer, settings, etc. is implemented using specialized components that can be mixed and matched to create a specific user experience or to provide additional functionality — some of them already known from Plasma Desktop.

Architecture diagram of Plasma Mobile

Architecture diagram of Plasma Mobile

Plasma Mobile is developed in a public and open development process. Contributions are welcome and encouraged throughout the process. We do not want to create another walled garden, but an inclusive platform for creation of mobile device user experiences. We do not want to create releases behind closed doors and throw them over the wall once in a while, but create a leveled playing field for contributors to work together and share their work. Plasma Mobile’s code is available on, and its development is discussed on the plasma-devel mailinglist. In the course of Akademy, we have a number of sessions planned to flesh out more and more detailed plans for further development.

With the basic workspace and OS integration work done, we have laid a good base for further development, and for others to get their code to run on Plasma Mobile. More work which is already in our pipeline includes support for running Android applications, which potentially brings a great number of mature apps to Plasma Mobile, better integration with other Plasma Devices, such as your desktop or laptop through KDE Connect, an improved SDK making it very easy to get a full-fledged development environment set up in minutes, and of course more applications.

July 15th, 2015

thoughts on being merciful binary gods

“Since when has the world of computer software design been about what people want? This is a simple question of evolution. The day is quickly coming when every knee will bow down to a silicon fist, and you will all beg your binary gods for mercy.” Bill Gates

For the sake of the users, let’s assume Bill was either wrong or (||) sarcastic.

Let’s say that we want to deliver Freedom and privacy to the users and that we want to be more effective at that. We plan to do that through quality software products and communication — that’s how we reach new users and keep them loving our software.

We can’t get away with half-assed software that more or less always shows clear signs of “in progress”, we need to think our software through from a users point of view and then build the software accordingly. We need to present our work at eye-level with commercial software vendors, it needs to be clear that we’re producing software fully reliable on a professional level. Our planning, implementation, quality and deployment processes need to be geared towards this same goal.

We need processes that allow us to deliver fixes to users within days, if not hours. Currently in most end-user scenario, it often takes months and perhaps even a dist-upgrade for a fix for a functional problem with our software.

The fun of all this lies in a more rewarding experience of making successful software, and learning to work together across the whole stack (including communication) to work together on this goal.

So, with these objectives in mind, where do we go from here? The answer is of course that we’re already underway, not at a very fast speed, but many of us have good understanding of many of the above structural goals and found solutions that work well.

Take tighter and more complete quality control, being at the heart of the implementation, as an example. We have adopted better review processes, more unit testing, more real-world testing and better feedback cycles with the community, especially the KDE Frameworks and Plasma stacks are well maintained and stabilized at high speeds. We can clearly say that the Frameworks idea worked very well technically but also from an organizational point of view, we have spread the maintainership over many more shoulders, and have been able to vastly simplify the deployment model (away from x.y.z releases). This works out because we test especially the Frameworks automatically and rather thoroughly through our CI systems. Within one year of Frameworks 5, our core software layer has settled into a nice pace of stable incremental development.

On the user interaction side, the past years have accompanied our interaction designers with visual artists. This is clearly visible when comparing Plasma 4 to Plasma 5. We have help from a very active group of visual designers now for about one and a half year, but have also adopted stricter visual guidelines in our development process and forward-thinking UI and user interaction design. These improvements in our processes have not just popped up, they are the result of a cultural shift towards opening the KDE also to non-coding contributors, and creating an atmosphere where designers feel welcome and where they can work productively in tandem with developers on a common goal. Again, this shows in many big and small usability, workflow and consistency improvements all over our software.

To strengthen the above processes and plug the missing holes in the big picture to make great products, we have to ask ourselves the right questions and then come up with solutions. Many of them will not be rocket science, some may take a lot of effort by many. This should not hold us back, as a commonly shared direction and goal is needed anyway, regardless of ability to move. We need to be more flexible, and we need to be able to move swiftly on different fronts. Long-standing communities such as KDE can sometimes feel to have the momentum of an ocean liner, which may be comfortable but takes ages to move, while it really should have the velocity, speed and navigational capabilities of a zodiak.

By design, Free Culture communities such as ours can operate more efficiently (through sharing and common ownership) than commercial players (who are restricted, but also boosted by market demands), so in principle, we should be able to offer competitive solutions promoting Freedom and privacy.

Our users need merciful binary source code gods and deserve top-notch silicon fists.

July 2nd, 2015

Convergence through Divergence

It’s that time of the year again, it seems: I’m working on KPluginMetaData improvements.

In this article, I am describing a new feature that allows developers to filter applications and plugins depending on the target device they are used on. The article targets developers and device integrators and is of a very technical nature.

Different apps per device

This time around, I’m adding a mechanism that allows us to list plugins, applications (and the general “service”) specific for a given form factor. In normal-people-language, that means that I want to make it possible to specify whether an application or plugin should be shown in the user interface of a given device. Let’s look at an example: KMail. KMail has two user interfaces, the desktop version, a traditional fat client offering all the features that an email client could possibly have, and a touch-friendly version that works well on devices such as smart phones and tablets. If both are installed, which should be shown in the user interface, for example the launcher? The answer is, unfortunately: we can’t really tell as there currently is no scheme to derive this information from in a reliable way. With the current functionality that is offered by KDE Frameworks and Plasma, we’d simply list both applications, they’re both installed and there is no metadata that could possibly tell us the difference.

Now the same problem applies to not only applications, but also, for example to settings modules. A settings module (in Frameworks terms “KCM”) can be useful on the desktop, but ignored for a media center. There may also be modules which provide similar functionality, but for a different use case. We don’t want to create a mess of overlapping modules, however, so again, we need some kind of filtering.

Metadata to the rescue

Enter KPluginMetaData. KPluginMetaData gives information about an application, a plugin or something like this. It lists name, icon, author, license and a whole bunch of other things, and it lies at the base of things such as the Kickoff application launcher, KWin’s desktop effects listing, and basically everything that’s extensible or uses plugins.

I have just merged a change to KPluginMetaData that allows all these things to specify what form factor it’s relevant and useful for. This means that you can install for example KDevelop on a system that can be either a laptop or a mediacenter, and an application listing can be adapted to only show KDevelop when in desktop mode, and skipping it in media center mode. This is of great value when you want to unclutter the UI by filtering out irrelevant “stuff”. As this mechanism is implemented at the base level, KPluginMetaData, it’s available everywhere, using the exact same mechanism. When listing or loading “something”, you simply check if your current formfactor is among the suggested useful ones for an app or plugin, and based on that you make a decision whether to list it or skip it.

With increasing convergence between user interfaces, this mechanism allows us to adapt the user interface and its functionality in a fully dynamic way, and reduces clutter.

Getting down and dirty

So, how does this look exactly? Let’s take KMail as example, and assume for the sake of this example that we have two executables, kmail and kmail-touch. Two desktop files are installed, which I’ll list here in short form.

For the desktop fat client:

Comment=Fat-client for your email

For the touch-friendly version:

Comment=Touch-friendly email client

Note that that “FormFactors” key does not just take one fixed value, but allows specifying a list of values — an application may support more than one form-factor. This is reflected throughout the API with the plural form being used. Now the only thing the application launcher has to do is to check if the current form-factor is among the supplied ones, for example like this:

foreach (const KPluginMetaData &app, allApps) {
    if (app.formFactors().count() == 0 || app->formFactors().contains("desktop")) {

In this example, we check if the plugin metadata does specify the form-factor by counting the elements, and if it does, we check whether “desktop” is among them. For the above mentioned example files, it would mean that the fat client will be added to the list, and the touch-friendly one won’t. I’ll leave it as an exercise to the reader how one could filter only applications that are specifically suitable for example for a tablet device.

What devices are supported?

KPluginMetaData does not itself check if any of the values make sense. This is done by design because we want to allow for a wide range of form-factors, and we simply don’t know yet which devices this mechanism will be used on in the future. As such, the values are free-form and part of the contract between the “reader” (for example a launcher or a plugin listing) and the plugins themselves. There are a few commonly used values already (desktop, mediacenter, tablet, handset), but in principle, adding new form-factors (such as smartwatches, toasters, spaceships or frobulators) is possible, and part of its design.

For application developers

Application developers are encouraged to add this metadata to their .desktop files. Simply adding a line like the FormFactors one in the above examples will help to offer the application on different devices. If your application is desktop-only, this is not really urgent, as in the case of the desktop launchers (Kickoff, Kicker, KRunner and friends), we’ll likely use a mechanism like the above: No formfactors specified means: list it. For devices where most of the applications to be found will likely not work, marking your app with a specific FormFactor will increase the chances of it being found. As applications are being adopted to respect the form-factor’s metadata, its usefulness will increase. So if you know your app will work well with a remote control, add “mediacenter”, if you know it works well on touch devices with a reasonably sized display, add “tablet”, and so on.


We now have basic API, but nobody uses it (a chicken-and-egg situation, really). I expect that one of the first users of this will be Plasma Mediacenter. Bhushan is currently working on the integration of Plasma widgets into its user interface, and he has already expressed interest in using this exact mechanism. As KDE software moves onto a wider range of devices, this functionality will be one of the cornerstones of the device-adaptable user interface. If we want to use device UIs to their full potential, we do not just need converging code, we also need to add divergence features to allow benefiting from the difference of devices.

May 3rd, 2015

Cuba Diving.

Spectacular sunset at Maria la Gorda

Spectacular sunset at Maria la Gorda

I recently went on a vacation to Cuba. As I wanted to go scuba diving there, I researched a bit beforehand. The information I could dig up was spotty at times, so I decided to share my notes in order to add it as anecdotal information when planning their diving trips.

During the 3 week trip to Cuba, I visited three locations in the south-western part of the island. In total, I did 19 dives along the Cuba coast, all of them very enjoyable. On the list were shallow (10-18m) coral reef dives, wall dives, some of them deep. I clocked my max depth at 34.1m. One of the things I wanted to do was a cave dive in a Cenote. Cenotes are underwater cave systems found around the geological area.

General Considerations

Dive boat at Maria la Gorda

Dive boat at Maria la Gorda

Cuba, being a Carribean island has a tropical climate with warm waters around it, and climatically a wet and a dry season. As the wet season may make the sea choppy, reduce visibility and carries the risk of hurricanes, it’s advisable to pick the dry seasons, months from November to May for diving activities. The South coast, which is where I have been diving had warm waters 27°C at the surface, and 26°C as depths down to about 35m. Visibility was generally excellent, commonly around 30m, with sometimes up to 50-60m in calm water. In several spots, there are large and well-preserved coral reefs. The South coast usually has calmer waters than the North coast, so I picked locations in the South-West: Maria La Gorda at the far southwestern point of the island, Playa Girón at the Bay of Pigs, and Playa Ancón near Trinidad. All turned out to be worth visiting and made for some amazing dives. (We also visited Cayo Levisa on Cuba’s Northern shore, which has a nice beach, but was mediocre at best for snorkeling from the shore. Go to Cayo Jutia instead, if you want good snorkeling, or book the boat to go diving at Cayo Levisa.)
Cuba is a communist country, instead of Coca Cola advertisements you’ll find some billboard reminding you that “the revolution is invincible”. Economic trade embargoes make acquiring scuba diving gear a problem (although I haven’t seen any shortcomings in this area myself). There’s usually just one dive center running the diving operations, so not much choice, but on the other hand, you’ll rarely encounter crowded dive sites, or reduced visibility due to other divers silting up the waters.

Touristic activities such as diving are usually possible through government-owned dive centers. There’s a network of official travel agents across the country, which can help you with booking trips and getting in contact with dive centers. Many of them are not easily reachable by phone, but you can sometimes book in advance of your trip online. In my experience, it would have been fine to just show up at the dive center at the right time of the day with your certification card and dive logs to prove your experience, and you’ll be almost good to go. I decided to bring my own gear, regulator, jacket BCD, 3mm wetsuit, fins, mask and torch in order to avoid any annoyances or unsafe situations due to flaky equipment.

My personal experience has been very positive, I loved the different dive sites, guides were generally skilled, and I had a whole bunch of amazing dives in Cuba. Would recommend.

Maria la Gorda

Maria la Gorda's beach

Maria la Gorda’s beach

Maria la Gorda is a bit off the beaten path in Cuba, one of the more remote locations on the main land. We travelled there from Vinales in 3 hours by car. The location itself is comprised of a hotel, two restaurants, and dive centre on a beautiful beach that also makes for some very nice snorkeling, you can basically walk in and enjoy lots of fish, even those not often discovered while scuba diving. Kim spotted barracuda, jacks, parrot fish, a moray and even an octopus just a few meters off the beach.
Diving there is done by boat 3 times a day. Almost all of the diving spots are within a 15min boat ride. The dive boat goes to 3 different sites a day, at 8:30, 11:00 and 15:00. It’s possible to also do a night dive, but has to be arranged with the staff. If you’re doing a day trip from Vinales just for diving, you’ll arrive in time to do two dives before leaving, the dive center does consider day guests. The surface time in between was enough to not dip too deep into nitrogen levels with 3 daily dives, the first two of them deep. Dives are usually limited to 45′ bottom time. If in general, you can’t get enough of scuba diving, that’s a lot of diving there.
The sites I’ve visited were all amazing in their own rights. Beautiful walls littered with coral, dropping down to 2000m right below you, really nice tunnels to dive through, large fan corals, barrel sponges of 3m and more, large groupers, jacks, and the usual variety of coral reef fish (parrot, box fish, angelfish, jacks, butterfly fish, etc.). Fish of more than 50cm in size were no exception, which seems like a sign that at least this part of the Carribean is comparably less overfished than other areas, there and especially in Asian countries.
The procedures on the boat were a bit unclear, I had liked to get better introduction there. Other people were happy to help, so this wasn’t much of a problem. The guides’ briefings were too short for my taste, especially knowing a bit about the navigation planned underwater would help to keep the group together more closely and in the end improves safety. I’ve asked the guide to tell me about the planned route under water, which he did in the following dives. That allowed me to take some responsibility myself (I really like to know under water that everybody who went into the water comes out of it as well). That said, there’s always room for improvement, and it didn’t lead to any dangerous situations. Taking responsibility for your buddies is part of diving, and as long as everybody takes it seriously, no problem.

Bahía de Cochinos (Bay of Pigs)

Museum in Playa Giron

Museum in Playa Giron

The Bay of Pigs is historically known for an attempt by the CIA to invade Cuba with US-friendly troops and overthrow the then-young communist government. Lack of political support from the US government, underestimation of the Cuban revolutionary troops and insufficient secrecy lead to an utter failure of the invasion attempt. Nowadays, the bay of pigs is a rather calm area, with excellent scuba diving. Basically, the eastern shore of the bay is lined with a coral reef wall very close to the shore. Commonly, one would do a shore entry here, swim out about 100m and then drop into the wall.
I dove with Ronel’s local dive operation. A tweaked bus would pick us up in the morning, go to the dive center (next to the government run hotel in Playa Giron) to gear up, and then drive up North for 10 – 20 minutes to one of the dive spots along the bay, then do two shore dives from there. We’d return around 1 o’clock in the afternoon, so there’s plenty of time for other activities (which, to be fair there aren’t that many apart from the beach and a “not-quite-neutral” museum about the failed invasion attempt).

The Cenote Dive

Entering the Cenote

Entering the Cenote

Cenotes are sinkholes in the shallow limestone ground near the coast. Small pools filled with fresh surface waters lead to extended cave systems flooded with salt water, so one enters a fresh water pool in the woods, then descends through a haloclyne. This haloclyne is the border between fresh and salt water. The caves were usually filled with salt water seeping in from the sea, but as there are almost no currents, rain water that comes in from above stays on top as fresh water. The haloclyne produces a weird disturbed visual effect when one dives through it, but above and underneath it, visibility is clear. These sink holes are often quite deep, the one we entered was 26m deep at entry point, the deepest points of the cave system went down to 60m. We entered into a tunnel, a vertical crack in the limestone about 1m wide, so wide enough to comfortably swim through. During the dive, we made our way about 350m into the cave to a maximum depth of 32m. As the shape of the cave determines the dive profile, I ended up having to add an extra decompression stop before surfacing.
We went through a lower tunnel into a larger cave, which had some beautiful sunlight shining in through cracks above in blue-green colors. Visibility was excellent, and the sunrays produced an almost magical ray of sunlight in the water of the deeper cave.
Descending into the Cenote

Descending into the Cenote

Through the haloclyne above us, the sunlight was broken by the different densities of air, fresh and salt water until they hit the particles drifting in the water or the walls and bottom and of the cave. This dive was guided by a specialized cave diving guide. Briefings were thorough, and after a first reef dive to check everyone’s buoyancy and general diving skills, we did our second dive of the day in the Cenote. I’ve found this video, which gives an impression how such a dive looks like. If you’re an advanced diver, comfortable with overhead environments and experienced enough, I’d definitely recommend doing a Cenote dive, For me, it’s been an unforgettable experience.

Playa Ancón

Playa Ancón is the beach village close to Trinidad. It’s a peninsula at about 7km from Trinidad. I’ve found it a bit complicated to book the diving there. Tour operator in Trinidad would tell me that everything’s fully booked, but inquiring at the dive center in Playa Ancon, I was told to just show up before 9am and I should be fine. That’s what I did, and it was indeed no problem to go diving there. We’d enter the boat from the beach and would go out a few hundred meters, just too much to swim there comfortably.
Even with a bit of a choppy sea that day, the diving was excellent. Good guides lead me over an interesting seascape with sandbed-“roads” in between coral fields, and much life in between. Highlights of these dives were a wreck, which lay across two large rocks and created a swimthrough this way, a school of tuna (about 40 fish), and a 1.2m large eagle ray. Water was warm and visibility in the range of 15m (considered quite bad for the location, so expect better when you get there). The dive shop was run professionally, but be prepared for a “laid-back scheduling”, which means depending on the day, two boat dives with a surface interval on shore might run into the early afternoon. (I’m mentioning it here, since every other dive center I dove with in Cuba was exceptionally punctual, contrary to what I had read before.)

March 9th, 2015

Spring dive.


Spring is just showing its first rays of sun, so we went diving today. We did a shallow dive in the morning in a lake close by, which is known for decent diving. The water was 4°C, so really chilly for a recreational dive, visibility under water about 5-7m, which is quite good for this kind of water. During our dive, we had really nice light as we didn’t go very deep and it’s been a really sunny day.

I’ve used Lycra undergarment and a 2mm neoprene bodywarmer under a 5mm wetsuit, 5mm neoprene gloves, hood and boots. My coldest dive so far was in 18 degrees water (in the same lake, late summer), so water that cold was quite something new. Richard, my buddy has a lot of experience also in these conditions, so I was in excellent hands.

After an initial bit of a shock when we entered the water, and a quick weighting / buoyancy check I gained back my serene diving breathing rhythm and started trusting the suit enough to become comfortable that it would keep me warm enough to take it for a swim. We went under for almost half an hour, but also took first signs of hypothermia seriously, in order to keep it safe and healthy. During the dive, we saw some fun fresh water lobsters, but also a fairly dormant ecosystem. I wanted to test out my new equipment, wireless integrated tank pressure gauge, jacket BCD, fins, regulator and an air tank I’ve borrowed from a neighbor, aside from the different layers of the suit.

I’m really happy with the new gear, everything functions perfectly, and there’s nothing that doesn’t have a clear purpose. I’ve taken a couple of notes for the next dive with this equipment, though those are only small adjustments, such as strapping on the tank a bit lower for a better weight distribution (which translates to a more hydrodynamic body position, meaning less exertion, lower air consumption and a more relaxed dive).

My next dive will be in 26°C water. Phew.