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:
Big 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.
QtCon 2016 is a special event: it co-hosts KDE’s Akademy, the Qt Contributor summit, the FSFE summit, the VideoLan dev days and KDAB’s training day into one big conference. As such, the conference is buzzing with developers and Free software people (often both traits combined in one person).
Naturally, the Plasma team is there with agenda’s filled to the brim: We want to tell more people about what Plasma has to offer, answer their questions, listen to their feedback and rope them in to work with us on Plasma. We have also planned a bunch of sessions to discuss important topics, let me give some examples:
- Release Schedule — Our current schedule was based on the needs of a freshly released “dot oh” version (Plasma 5.0), Plasma 5 is now way more mature. Do we want to adjust our release schedule of 4 major versions a year to that?
- Convergence — How can we improve integration of touch-friendly UIs in our workflows?
- What are our biggest quality problems right now, and what are we going to do about it?
- How do we make Plasma Mobile available on more devices, what are our next milestones?
- How can we improve the Plasma session start?
- What’s left to make Plasma on Wayland ready for prime-time?
- How can we improve performance further?
You see, we’re going to be really busy here. You won’t see results of this next week, but this kind of meeting is important to flesh out our development for the next months and years.
I’ve done a facelift to my website. The new version is more mobile-friendly, modern-looking and quite a departure visually from its original look. I’ve chosen for a newpaper-like, typography-based responsive layout. My site finally also supports SSL, thanks to let’s encrypt.
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.
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.
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.
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.
We visited the CMS today, the Compact Muon Solenoid, one of the “experiments” that are part of the LHC, the large hadron collider, which is a research project aiming to find out more about the basic structures that make up our universe, like how gravity works, which particles make up our universe, and so on.
In order to do that, researchers accelerate elementary particles to almost the speed of light, make them crash into each other and record this process. There’s a 27km long circular tunnel 100m below the ground near Geneva, Switzerland (the tunnel actually extends into France, so the CMS experiment is located in France).
As we’re currently at a KDE Plasma sprint at CERN, the European Research center for nuclear energie, we were invited to a tour through the CMS. We got to learn a lot about physics and also descended down into the chamber holding the giant CMS machine. (It’s switched off currently, since energy costs during winter are too high to run it — it takes a lot of power to accelerate particles to almost the speed of light, in the range of 200 Megawatt). There’s some maintenance work going on right now before this monster is switched on again towards the end of the month.
CERN staff were friendly and patient and answered all our questions. The tour was interesting and a lot of fun.
Here are some more pictures I took during the visit. You may notice that some of the computers in the control room are running Plasma on their desktops.
More photos of my visit can be found here.
I’ve just finished my travel preparations for this year’s Plasma sprint, which will start tomorrow with the arrival of my fellow hackers in Geneva, CH. Together with a few other groups in KDE and organized by our WikiToLearn friends, we’re honored to be guests at CERN, the European Organization for Nuclear Research where physicists and engineers are probing the fundamental structure of the universe. Of course, these scientists and engineers couldn’t do their work without Plasma, so we’re obliged to hold our meeting there. :-)
Topics range from our Wayland support to Plasma Mobile, documentation, how we can improve our desktop experience, and general planning for the next months. I’m also looking forward to some face-time with my fellow hackers, and discussions with the artists and usability experts who are holding a meeting of the visual design group in KDE. Only good stuff can come out of this.
Many thanks go to all the people who support KDE. This support makes meetings like next week’s possible. Please consider supporting us.
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.
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 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.