Rocket ScienceThe calm days between christmas and new year are best celebrated with your family (of choice), so I went to Hamburg where the 33rd edition of the Chaos Computer Congress opened the door to 12.000 hackers, civil rights activists, makers and people interested in privacy and computer security. The motto of this congress is “works for me” which is meant as a critical nudge towards developers who stop after technology works for them, while it should work for everyone. A demand for a change in attitude.
33C3’s ballroom
The congress is a huge gathering of people to share information, hack, talk and party, and the past days have been a blast. This congress strikes an excellent balance between high quality talks, interesting hacks and electronics and a laid back atmosphere, all almost around the clock. (Well, the official track stops around 2 a.m., but continues around half past eleven in the morning.) The schedule is really relaxed, which makes it possibly to party at night, and interrupt dancing for a quick presentation about colonizing intergalactic space — done by domain experts.
The conference also has a large unconference part, hacking spaces, and lounge areas, meaning that the setup is somewhere in between a technology conference, a large hack-fest and a techno party. Everything is filled to the brim with electronics and decorated nicely, and after a few days, the outside world simply starts to fade and “congress” becomes the new reality.
No Love for the U.S. Gov
I’ve attended a bunch of sessions on civil rights and cyber warfare, as well as more technical things. One presentation that touched me in particular was the story of Lauri Love, who is accused of stealing data from agencies including Federal Reserve, Nasa and FBI. This talk was presented by a civil rights activist from the Courage foundation, and two hackers from Anonymous and Lulzsec. While Love is a UK citizen, the US is demanding extradition from the UK so they can prosecute him under US law (which is much stricter than the UK’s). This would create a precedent making it much easier for the US to essentially be able to prosecute citizens anywhere under US law.
What kind of technoparty^W congres is this?This, combined with the US jail system poses a serious threat to Love. He wouldn’t be the first person to commit suicide under the pressure put on him by the US government agencies, who really seem to be playing hardball here. (Chelsea Manning, the whistleblower behind the videos of the baghdad airstrikes, in which US airforce killed innocent citizens carelessly, among others) who suffered from mental health issues, was put into solitary confinement, instead of receiving health care. Against that background, the UK would send one of their own citizens into a jail that doesn’t even respect basic human rights. On particularly touching moment was when the brother of Aaron Swartz took the microphone and appealed to the people who asked how they could prevent another Aaron, that helping Lauri (and Chelsea) is the way to help out, and that’s where the energy should be put. Very moving.
The media team at this event is recording most of the sessions, so if you have some time to spare, head over to media.ccc.de and get your fix. See you at 34C3!
My Plasma Desktop in 2016On Monday, KDE’s Plasma team held its traditional kickoff meeting for the new development cycle. We took this opportunity to also look and plan ahead a bit further into the future. In what areas are we lacking, where do we want or need to improve? Where do we want to take Plasma in the next two years?
Our general direction points towards professional use-cases. We want Plasma to be a solid tool, a reliable work-horse that gets out of the way, allowing to get the job done quickly and elegantly. We want it to be faster and of better quality than the competition.
With these big words out there, let’s have a look at some specifics we talked about.
Release schedule until 2018
Our plan is to move from 4 to 3 yearly releases in 2017 and 2018, which we think strikes a nice balance between our pace of development, and stabilization periods around that. Our discussion of the release schedule resulted in the following plan:
Plasma 5.9: 31 January 2017
Plasma 5.10: May 2017
Plasma 5.11: September 2017
Plasma 5.12: December 2017
Plasma 5.13: April 2018
Plasma 5.14 LTS: August 2018
A cautionary note, we can’t know if everything exactly plays out like this, as this schedule, to a degree depends on external factors, such as Qt’s release schedule. Here’s what we intend to do, it is really our “best guess”. Still, this aligns with Qt’s plans, who are also looking at an LTS release in summer 2018. So, what will these upcoming releases bring?
Breeze Look and Feel
UI and Theming
The Breeze icon theme will see further completion work and refinements in its existing icons details. Icon usage over the whole UI will see more streamlining work as well. We also plan to tweak the Breeze-themed scrollbars a bit, so watch out for changes in that area. A Breeze-themed Firefox theme is planned, as well as more refinement in the widget themes for Qt, GTK, etc.. We do not plan any radical changes in the overall look and feel of our Breeze theme, but will further improve and evolve it, both in its light and dark flavors.
Feature back-log
The menu button is a first sign of the global menu returning to PlasmaOne thing that many of our users are missing is support for a global menu similar to how MacOS displays application menus outside of the app’s window (for example at the top of the screen). We’re currently working on bringing this feature, which was well-supported in Plasma 4 back in Plasma 5, modernized and updated to current standards. This may land as soon as the upcoming 5.9 release, at least for X11.
Better support for customizing the locale (the system which shows things like time, currencies, numbers in the way the user expects them) is on our radar as well. In this area, we lost some features due to the transition to Frameworks 5, or rather QLocale, away from kdelibs’ custom, but sometimes incompatible locale handling classes.
Wayland
The next releases overall will bring further improvements to our Wayland session. Currently, Plasma’s KWin brings an almost feature-complete Wayland display server, which already works for many use-cases. It hasn’t seen the real-world testing it needs, and it is lacking certain features that our users expect from their X11 session, or new features which we want to offer to support modern hardware better.
We plan to improve multi-screen rendering on Wayland and the input stack in areas such as relative pointers, pointer confinement, touchpad gestures, wacom tablet support, clipboard management (for example, Klipper). X11 dependencies in KWin will be further reduced with the goal to make it possible to start up KWin entirely without hard X11 dependencies.
One new feature which we want to offer in our Wayland session is support for scaling the contents of each output individually, which allows users to use multiple displays with vastly varying pixel densities more seamlessly.
There are also improvements planned around virtual desktops under Wayland, as well as their relation to Plasma’s Activities features. Output configuration as of now is also not complete, and needs more work in the coming months. Some features we plan will also need changes in QtWayland, so there’s some upstream bug-fixing needed, as well.
One thing we’d like to see to improve our users’ experience under Wayland is to have application developers test their apps under Wayland. It happens still a bit too often that an application ends up running into a code-path that makes assumptions that X11 is used as display server protocol. While we can run applications in backwards-compatible XWayland mode, applications can benefit from the better rendering quality under Wayland only when actually using the Wayland protocol. (This is mostly handled transparantly by Qt, but applications do their thing, so unless it’s tested, it will contain bugs.)
Mobile
Plasma’s Mobile flavor will be further stabilized, and its stack cleaned up, we are further reducing the stack’s footprint without losing important functionality. The recently-released Kirigami framework, which allows developers to create convergent applications that work on both mobile and desktop form-factors, will be adjusted to use the new, more light-weight QtQuick Controls 2. This makes Kirigami a more attractive technology to create powerful, yet lean applications that work across a number of mobile and desktop operating systems, such as Plasma Mobile, Android, iOS, and others.
Discover, Plasma’s software center integrates online content from the KDE Store, its convergent user-interface is provided by the Kirigami framework
Online Services
Planned improvements in our integration of online services are dependency handling for assets installed from the store. This will allow us to support installation of meta-themes directly from the KDE Store. We want to also improve our support for online data storage, prioritizing Free services, but also offer support for proprietary services, such as the GDrive support we recently added to Plasma’s feature-set.
Developer Recruitment
We want to further increase our contributor base. We plan to work towards an easier on-boarding experience, through better documentation, mentoring and communication in general. KDE is recruiting, so if you are looking for a challenging and worthwhile way to work as part of a team, or on your individual project, join our ranks of developers, artists, sysadmins, translators, documentation writers, evangelists, media experts and free culture activists and let us help each other.
Our upcoming release, Plasma 5.8 will be the first long-term supported (LTS) release of the Plasma 5 series. One great thing of this release is that it aligns support time-frames across the whole stack from the desktop through Qt and underlying operating systems. This makes Plasma 5.8 very attractive for users need to that rely on the stability of their computers.
Qt, Frameworks & Plasma
In the middle layer of the software stack, i.e. Qt, KDE Frameworks and Plasma, the support time-frames and conditions roughly look like this:
Qt 5.6
Qt 5.6 has been released in March as the first LTS release in the Qt 5 series. It comes with a 3-year long-term support guarantee, meaning it will receive patch releases providing bug fixes and security updates.
Frameworks 5.26
In tune with Plasma, during the recent Akademy we have decided to make KDE Frameworks, the libraries that underlie Plasma and many KDE applications 18 months of security support and fixes for major bugs, for example crashes. These updates will be shipped as needed for single frameworks and also appear as tags in the git repositories.
Plasma 5.8
The core of our long-term support promise is that Plasma 5.8 will receive at least 18 months of bugfix and security support from upstream KDE. Patch releases with bugfix, security and translation updates will be shipped in fibonacci rhythm.
To make this LTS extra reliable, we’ve concentrated the (still ongoing) development cycle for Plasma 5.8 on stability, bugfixes, performance improvements and overall polish. We want this to shine.
There’s one caveat, however: Wayland support excluded from long-term-support promises, as it is too experimental. X11 as display server is fully supported, of course.
Neon and Distros
You can enjoy these LTS releases from the source through a Neon flavor that ships an updated LTS stack based on Ubuntu’s 16.04 LTS version. openSuse Leap, which focuses on stability and continuity also ships Plasma 5.8, making it a perfect match.
The Plasma team encourages other distros to do the same.
Post LTS
After the 5.8 release, and during its support cycle, KDE will continue to release feature updates for Plasma which are supported through the next development cycle as usual.
Lars Knoll’s Qt roadmap talk (skip to 29:25 if you’re impatient and want to miss an otherwise exciting talk) proposes another Qt LTS release around 2018, which may serve as a base for future planning in the same direction.
It definitely makes a lot of sense to align support time-frames for releases vertically across the stack. This makes support for distributions considerably easier, creates a clearer base for planning for users (both private and institutional) and effectively leads to less headaches in daily life.
The QtCon / Akademy organizers have published the videos of last weekend’s conference presentations. If you’re interested in the topic, you can watch the video of my presentation about the KDE Software Store here:
I’ve also uploaded my slides, and you can find the rest of the QtCon presentation videos here.
KDE StoreBig news: Today, KDE announced a new software store, and that the source code for this new service has been released as Free software under the AGPL, fixing a long standing bug in KDE software: reliance on a proprietary web service.
That also means that KDE has a new software store that replaces the opendesktop sites. The migration has been happening in the background, so you may actually have used the new store from within Plasma or applications to install add-ons already without noticing it!
We have great plans for the store, one of them being that we want to offer download (and easy installation) of binary packages through containerized bundled formats such as Flatpak, Snappy and/or AppImage.
Stay tuned for more, for now, please celebrate with us a Plasma desktop (and KDE applications) that are more Free than ever before.
Plasma 5.8 will be our first long-term supported release in the Plasma 5 series. We want to make this a release as polished and stable as possible. One area we weren’t quite happy with was our multi-screen user experience. While it works quite well for most of our users, there were a number of problems which made our multi-screen support sub-par.
Let’s take a step back to define what we’re talking about.
Multi-screen support means that connecting more than one screen to your computer. The following use cases give good examples of the scope:
Static workstation A desktop computer with more than one display connected, the desktop typically spans both screens to give more screen real estate.
Docking station A laptop computer that is hooked up to a docking station with additional displays connected. This is a more interesting case, since different configurations may be picked depending on whether the laptop’s lid is closed or not, and how the user switches between displays.
Projector The computer is connected to a projector or TV.
The idea is that the user plugs in or starts up with that configuration, if the user has already configured this hardware combination, this setup is restored. Otherwise, a reasonable guess is done to put the user to a good starting point to fine-tune the setup.
This is the job of KScreen. At a technical level, kscreen consists of three parts:
system settings module This can be reached through system settings
kscreen daemon Run in a background process, this component saves, restores and creates initial screen configurations.
libkscreen This is the library providing the screen setup reading and writing API. It has backends for X11, Wayland, and others that allow to talk to the exact same programming interface, independent of the display server in use.
At an architectural level, this is a sound design: the roles are clearly separated, the low-level bits are suitably abstracted to allow re-use of code, the API presents what matters to the user, implementation details are hidden. Most importantly, aside from a few bugs, it works as expected, and in principle, there’s no reason why it shouldn’t.
So much for the theory. In reality, we’re dealing with a huge amount of complexity. There are hardware events such as suspending, waking up with different configurations, the laptop’s lid may be closed or opened (and when that’s done, we don’t even get an event that it closed, displays come and go, depending on their connection, the same piece of hardware might support completely different resolutions, hardware comes with broken EDID information, display connectors come and go, so do display controllers (crtcs); and on top of all that: the only way we get to know what actually works in reality for the user is the “throw stuff against the wall and observe what sticks” tactic.
This is the fabric of nightmares. Since I prefer to not sleep, but hack at night, I seemed to be the right person to send into this battle. (Coincidentally, I was also “crowned” kscreen maintainer a few months ago, but let’s stick to drama here.)
So, anyway, as I already mentioned in an earlier blog entry, we had some problems restoring configurations. In certain situations, displays weren’t enabled or positioned unreliably, or kscreen failed to restore configurations altogether, making it “forget” settings.
Better tools
Debugging these issues is not entirely trivial. We need to figure out at which level they happen (for example in our xrandr implementation, in other parts of the library, or in the daemon. We also need to figure out what happens exactly, and when it does. A complex architecture like this brings a number of synchronization problems with it, and these are hard to debug when you have to figure out what exactly goes on across log files. In Plasma 5.8, kscreen will log its activity into one consolidated, categorized and time-stamped log. This rather simple change has already been a huge help in getting to know what’s really going on, and it has helped us identify a number of problems.
A tool which I’ve been working on is kscreen-doctor. On the one hand, I needed a debugging helper tool that can give system information useful for debugging. Perhaps more importantly I know I’d be missing a command-line tool to futz around with screen configurations from the command-line or from scripts as Wayland arrives. kscreen-doctor allows to change the screen configuration at runtime, like this:
Disable the hdmi output, enable the laptop panel and set it to a specific mode
$ kscreen-doctor output.HDMI-2.disable output.eDP-1.mode.1 output.eDP-1.enable
Position the hdmi monitor on the right of the laptop panel
$ kscreen-doctor output.HDMI-2.position.0,1280 output.eDP-1.position.0,0
Please note that kscreen-doctor is quite experimental. It’s a tool that allows to shoot yourself in the foot, so user discretion is advised. If you break things, you get to keep the pieces. I’d like to develop this into a more stable tool in kscreen, but for now: don’t complain if it doesn’t work or eat your hamster.
Another neat testing tool is Wayland. The video wall configuration you see in the screenshot is unfortunately not real hardware I have around here. What I’ve done instead is run a Wayland server with these “virtual displays” connected, which in turn allowed me to reproduce a configuration issue. I’ll spare you the details of what exactly went wrong, but this kind of tricks allows us to reproduce problems with much more hardware than I ever want or need in my office. It doesn’t stop there, I’ve added this hardware configuration to our unit-testing suite, so we can make sure that this case is covered and working in the future.
Here’s a quick status update about where we currently stand with respect to multiscreen support in Plasma Desktop.
While for many people, multiscreen support in Plasma works nicely, for some of our users, it doesn’t. There are problems with restoring previously set up configurations, and around the primary display mechanism. We’re really unhappy about that, and we’re working on fixing it for all of our users. These kinds of bugs are the stuff nightmares are made of, so there’s not a silver bullet to fix everything of it, once and for all right away. Multiscreen support requires many different components to play in tune with each other, and they’re usually divided into separate processes communicating via different channels with each other. There’s X11 involved, XCB, Qt, libkscreen and of course the Plasma shell. I can easily at least three different protocols in this game, Wayland being a fourth (but likely not used at the same time as X11). There’s quite some complexity involved, and the individual components involved are actually doing their jobs quite well and have their specific purposes. Let me give an overview.
Multiscreen components
Plasma Shell renders the desktop, places panels, etc., When a new screen is connected, it checks whether it has an existing configuration (wallpaper, widgets, panels etc.) and extends the desktop. Plasma shell gets its information from QScreen now (more on that later on!)
KWin is the compositor and window manager. KWin/X11 interacts with X11 and is responsible for window management, movement, etc.. Under Wayland, it will also take the job of the graphical and display server work that X11 currently does, though mostly through Wayland and *GL APIs.
KScreen kded is a little daemon (actually a plugin) that keeps track of connected monitors and applies existing configs when they change
KScreen is a module in systemsettings that allows to set up the display hardware, positioning, resolution, etc.
Libkscreen is the library that backs the KScreen configuration. It offers an API abstraction over XRandR and Wayland. libkscreen sits pretty much at the heart of proper multiscreen support when it comes to configuring manually and loading the configuration.
Primary Desktop
The primary display mechanism is a bit of API (rooted in X11) to mark a display as primary. This is used to place the Panel in Plasma, and for example to show the login manager window on the correct monitor.
Libkscreen and Qt’s native QScreen are two different mechanism to reflect screen information. QScreen is mainly used for querying info (and is of course used throughout QtGui to place windows, get information about resolution and DPI, etc.). Libkscreen has all this information as well, but also some more, such as write support. Libkscreen’s backends get this information directly from Xorg, not going through Qt’s QScreen API. For plasmashell, we ended up needing both, since it was not possible to find the primary display using Qt’s API. This causes quite some problems since X11 is async by its nature, so essentially we ended up having “unfixable” race conditions, also in plasmashell. These are likely the root cause of the bug you’re seeing here.
This API has been added in Qt 5.6 (among a few other fixes) by Aleix Pol, one of our devs in the screen management team. We have removed libkscreen from plasmashell today and replaced it with “pure QScreen” code, since all the API we need for plasmashell is now available in the Qt we depend on.
These changes should fix much of the panel placement grief that bug 356225 causes. It does need some good testing, now it’s merged. Therefore, we’d like to see as many people, especially those reporting problem with multiscreen, to test against latest Plasma git master (or the upcoming Plasma 5.7 Beta, which is slated for release on June, 16th).
Remember the config
Another rough area that is under observation right now is remembering and picking the right configuration from a previous setup, for example when you return to your docking station which has another display connected. Bug 358011 is an example for that. Here, we get “spurious” events about hardware changes from X11, and I’m unsure where they come from. The problem is that it’s not easy to reproduce, it only happens for certain setups. This bug was likely introduced with the move to Qt 5 and Frameworks, it’s a regression compared to Plasma 4.
I’ve re-reviewed the existing code, added more autotests and made the code more robust in some places that seemed relevant, but I can’t say that we’ve found a sure solution to these problems. The code is now also better instrumented for debugging the areas at play here. Now we need some more testing of the upcoming beta. This is certainly not unfixable, but needs feedback from testing so we can apply further fixes if needed.
Code quality musings
From a software engineering point of view, we’re facing some annoying problems. It took us a long time to get upstream QScreen code to be robust and featureful enough to draw the lines between the components involved, especially QScreen and libkscreen more clearly, which certainly helps to reduce hard-to-debug race conditions involving hardware events. The fact that it’s almost impossible to properly unit test large parts of the stack (X11 and hardware events are especially difficult in that regard) means that it’s hard to control the quality. On the other hand, we’re lacking testers, especially those that face said problems and are able to test the latest versions of Qt and Plasma.
QA processes is something we spent some serious work on, on the one hand, our review processes for new code and changes to current code are a lot stricter, so we catch more problems and potential side-effects before code gets merged. For new code, especially the Wayland support, our QA story also looks a lot better. We’re aiming for near-100% autotest coverage, and in many cases, the autotests are a lot more demanding than the real world use cases. Still, it’s a lot of new code that needs some real world exposure, which we hope to get more of when users test Plasma 5.7 using Wayland.
I am concerned. In the past years, it has become clear that real privacy has become harder to come by. Our society is quickly heading into a situation where an unknown number of entities and people can follow my every single step, and it’s not possible to keep to myself what I don’t want others to know. With every step into that direction, there’s less and less things about my life of which I don’t control who knows about it.
Privacy as product or weapon
Realistically, I won’t be able to do that, however, since in this modern age, tools that need to share data are rather the norm, than the exception. Most of the time, this sharing of data (even if only between my own devices) goes through the hand of a third party. On top of that, there’s a whole lot of spying going on, and of course malicious hackers which are keen to acquire large personal sets of identity data. My personal data can make me a product, and worse, it can be used as a weapon against myself. It is really in my best interest to share only the absolute minimal amount of data with as little others as possible.
Traditionally, this urgency for privacy has been closely connected to the goals of Free software. This is not a coincidence. Free software and was intended as a way to give control to the users, and copyleft is an effective tool to achieve “software democracy”, in the best interest of the user. In reverse, someone who is not in control of his data cannot truly be free. Privacy and freedom are in fact closely related concepts.
Software Freedom: economics and ideology
I prefer Free software over proprietary solutions. It puts me in control what my machine does, it allows me to fulfill my needs and influence the tools I use for communication, work and entertainment into a direction that is driven by value to the user, rather than return-on-investment measured in money.
When I started using computers, Free software was sub-par to proprietary solutions, that is largely not the case anymore. In many cases, Free software surpasses what proprietary alternatives offer. In a lot of areas, Free software has come to dominate the market.
This is not surprising, given the economic model behind Free software. In the long run, building on the shoulder of giants, sharing the work across more stakeholders, open code and processes are more economical, scale better and tend to be more sustainable.
The ideological point of view benefits from that, I can lead a fully functional digital life using almost exclusively Free software and I certain guarantees of continuity often unmet in the proprietary world.
Shifting purpose
To me, the purpose of Free software has shifted a bit, or rather expands to enabling privacy. A good measurement whether the Free software movement has achieved its goal is the degree of privacy it allows me to have, while enabling all the modern amendments that our digital age makes possible, or even just to have a private conversation with a friend.
Effective privacy
Effective privacy needs network effects, so it doesn’t work very well for niche products. Of what use is a secure and private communication tool if I can’t use it to talk with my friends? Luckily the initial successes of Free software still play in our advantage: being able to collaboratively develop and share the work across many shoulders, we should be able to not just build all the pieces, but put together a complete set of solutions that make better privacy achievable for more people. In terms of achieving network effects, we’re not starting at zero, but our adversaries are strong, and often ahead of our game, some tend to play unfair.
Purpose means responsibility
Is it not our responsibility as Free software community (or even just as citizens) to provide the tools that maximize privacy for the users? If the answer is yes, then I suppose the measurement for success is how much can we make possible while maximizing privacy? How attractive can we make the tools in terms of functionality, effectiveness and availability?
A happy user is one who finds that a useful and fun-to-use tool also protects him from threats that he often may not fully appreciate until it’s too late.
Marco has come over to the Netherlands to pay me a visit, and to hack a little bit together, in person. So with the weather clearly suggesting to stay inside, that’s what we did over the weekend, and how better to entertain yourself than to work on mobile software?
Marco has been working for a while on components that follow Plasma’s human interface guidelines and make it easy to implement applications with a common navigation pattern and look and feel. Obviously, these components use a lot of Plasma under the hood, so they get excellent integration at a visual and at a technical level. This high integration, however, comes at the price of having a non-trivial chain of dependencies. That’s not a problem in Plasma Mobile, or other Plasma workspaces, since all that is already there, anyway.
We thought that an interesting exercise would be to find out what really defines a “Plasma application”, and how we can make the concepts we engrained in their design available to application developers more easily. How hard could it be to use Plasma components in an Android app, for example? The answer is, not entirely trivial, but it just became a whole lot easier. So what did we do?
For those reading this article via a feed aggregator, hop over to youtube to watch the demo video.
We took Subsurface, which is a piece of Free software used for logging and analysing scuba dives. Subsurface has a mobile version, which is still in its infancy, so it’s an excellent candidate to experiment with. We also took Marco’s set of Plasma components that provide a reduced set of functionality, in fact, just enough to create what most applications will need. These components extend QtQuick components where we found them lacking. They’re very light weight, carry no dependencies other than QtQuick, and they’re entirely written in QML, so basically, you add a bunch of QML files to your app and concentrate on what makes your app great, not on overall navigation components or re-implementing for the n-th time a set of widgets.
So after solving some deployment issues, on Saturday night, we had the Plasma mobile components loading in an Android app. A first success. Running the app did show a number of problems, however, so we spent most of the Sunday to look into each problem one by one and trying to solve them. By early Monday morning, we had all of the glaring issues we found during our testing solved, and we got Subsurface mobile to a pretty solid appearance (pretty solid given its early state of development, not bug free by any means).
So, what to take a away from this? In a reduced form, Plasma can be a huge help to create also Android applications. The mobile components which we’re developing with Plasma Mobile as target in mind have had their first real world exposure and a lot of fixes, we got very useful feedback from the Subsurface community which we’re directly feeding back into our components.
A big thanks goes out to the Subsurface team and especially Dirk Hohndel for giving us excellent and timely feedback, for being open to our ideas and for willing to play guinea pig for the Plasma HIG and our components. The state you can see in the above video has already been reviewed and merged into Subsurface’s master tree, so divers around the world will be able to enjoy it when the app becomes available for a wider audience.
kscreen wayland backend in actionThat moment when the application “just works” after all your unit tests pass…
A really nice experience after working on these low-levelbits was firing up the kscreen systemsettings module configured to use my wayland test server. I hadn’t done so in a while, so I didn’t expect much at all. The whole thing just worked right out of the box, however. Every single change I’ve tried had exactly the expected effect.
This screenshot shows Plasma’s screen configuration settings (“kscreen”). The settings module uses the new kwayland backend to communicate with a wayland server (which you can see “running” on the left hand side). That means that another big chunk of getting Plasma Wayland-ready for multi-display use-cases is falling nicely into place.
testing
I’m working on this part of the stack using test-driven development methods, so I write unit tests for every bit of functionality, and then implement and polish the library parts. Something is done when all units tests pass reliably, when others have reviewed the code, when everything works in on the application side, and when I am happy with it.
The unit tests stay in place and are from then on compiled and run through our continuous integration system automatically on every code change. This system yells at us as soon as any of the unit tests breaks or shows problems, so we can fix it right away.
Interestingly, we run the unit tests live against a real wayland server. This test server is implemented using the KWayland library. The server runs headless, so it doesn’t do any rendering of windows, and it just implements the bits interesting for screen management. It’s sort of a mini kwin_wayland, the real kwin will use this exact same library on the server side, so our tests are not entirely synthetical. This wasn’t really possible for X11-based systems, because you can’t just fire up an X server that supports XRandR in automated tests — the machine running the test may not allow you to use its graphics card, if it even has one. It’s very easy to do, however, when using wayland.
Our autotests fire up a wayland server from one of many example configurations. We have a whole set of example configurations that we run tests against, and it’s easy to add more that we want to make sure work correctly. (I’m also thinking about user support, where we can ask to send us a problematic configuration written out to a json file, that we can then add to our unit tests, fix, and ensure that it never breaks again.
The wayland test server is only about 500 lines of relatively simple code, but it provides full functionality for setting up screens using the wayland protocol.
Next steps…
The real kwin_wayland will use the exact same library, on the server as we do in our tests, but instead of using “virtual screens”, it does actually interact with the hardware, for example through libdrm on more sensible system or through libhybris on ones less so.
Kwin takes a more central role in our wayland story, as we move initial mode-setting there, it just makes to have it do run-time mode setting as well.
The next steps are to hook the server side of the protocol up in kwin_wayland’s hardware backends.
In the back of my head are a few new features, which so far had a lower priority — first the core feature set needed to be made stable. There are three things which I’d like to see us doing:
per-display scaling — This is an interesting one. I’d love to be able to specify a floating point scaling factor. Wayland’s wl_output interface, which represents the application clients, only provides int-precision. I think that sucks since there is a lot of hardware around where a scaling factor of 1 is to small, and 2 is too high. That’s pretty much everything between 140 and 190 DPI according to my eyesight, your mileage may vary here. I’m wondering if I should go ahead and add the necessary API’s at least on our end of the stack to allow better than integer precision.
Also, of course we want the scaling be controlled per display (and not globally for all displays, as it is on X11), but that’s in fact already solved by just using wayland semantics — it needs to be fixed on the rendering side now.
pre-apply checks — at least the drm backend will allow us to ask it if it will be able to apply a new configuration to the hardware. I’d love to hook that up to the UI, so we can do things like enable or disable the apply button, and warn the user of something that the hardware is not going to like doing.
The low-level bits have arrived with the new drm infrastructure in the kernel, so we can hook it up in the libraries and the user interface.
configuration profiles — it would make sense to allow the user to save configurations for different situations and pick between them. It would be quite easy to allow the user to switch between setups not just through the systemsettings ui, but also for example when connecting or disabling a screen. I an imagine that this could be presented very nicely, and in tune with graphical effects that get their timing juuuuust right when switching between graphics setups. Let’s see how glitch-free we can make it.
