You're probably wondering what I was doing at 1am last night. I get asked that all the time. Well, mostly by people I live with, now that I think about it. "What were you doing on your computer at one in the morning?" they ask. The answer is usually quite exciting. Take last night, for instance: I was having a meeting with people to discuss display managers. Yes, the wonderful world of login screens.
We now have a truly amazing spreadsheet that tabulates the current state of three display managers. It has sections from community, "soft" attributes (such as licensing and build system), technology support, features and performance. Unfortunately, this did not lead us to any firm conclusions but it was very useful in helping better understand the landscape here, which is what we were after.
Our Requirements
The question we are trying to answer is this: What display manager will we use in Plasma Workspaces 2? Candidates must match a simple and clear set of needs:
- Must be lightweight. We want to use this on desktops and devices.
- Must be maintainable. (Self explanatory.)
- Must be able to write the user interface in QML.
- Must be able to be a Wayland system compositor.
How hard can that be, right? ;) Bonus points are awarded for things like:
- Used by other projects (co-investment and user consistency)
- Familiar tooling (we can always learn and use another revision control system, but we'd rather not as that raises the bar for participation)
Given that as a starting point we looked at three options and here's what my take-away on each was.
Contestant #1: KDM
This contestant is a deep soul with much complexity who likes things the old-fashioned way. 20 year old scotch is its drink of choice, and it hates walks on the beach (not much of a romantic, you see). It holds advanced degrees in many traditional practices. Let's say hello to .. KDM!
KDM does a lot of things very well. It is highly scalable (10k users in LDAP? No problem.), supports features such as remote log in, can be used with hardware and biometric keys and much more. It is themable, as a
Google images search can quickly confirm.
Unfortunately, there has not been much work on it lately and none of the active developers know the codebase very well. And what a codebase it is! 34,000+ lines of code, nearly 14,000 lines of which are C with the rest mostly C++. It is a beast. Interestingly, the KDM settings UI is 6,400+ lines of C++. That makes it's control panel nearly twice as big in terms of code count as the Plasma Active shell.
Work had been started on making a QML front end for it (twice, I believe) but it never came to full fruition, and it is unclear just how best to add a Wayland system comositor to KDM would be. So though it has served us well, KDM actually fails to meet our requirements.
Contestant #2: LightDM
This contestant is a young but accomplished fellow with lots of modern features. An outgoing sort, he strives to be useful to all around him and tries not to make many assumptions about what would make you happy. With lots of friends, he's seen at the entrance to many parties .. say hello to: LightDM!
With just over 20,000 lines of C code (though getting closer to 22,000 with the KDE integration bits), LightDM has a terrific number of features. It has a clear separation between the toolkit-agnostic backend and user interface providing front-ends that communicate via a local socket to get the deed done.
Guest login, auto-login, VNC/RDP/XDMCP, power management, fast user switching .. it's all there. Outside of a few things like biometrics, it has a superset of KDM's features. It also has support for new Linux middleware such as systemd and AccountsService, and does it all with a very small footprint (the daemon takes well under 1MB of RAM). It is also quite extensible and used by a large number of projects including the *buntu family of Linux distributions, RazorQt, Elementary and XBMC.
There are three main contributors to the core LightDM according to the commit logs, all of whome work at Canonical. In addition to their efforts, David Edmundson's has been working on KDE integration for LightDM in KDE's repositories. Thanks to his work, you can write your UI in QML and PowerDevil is used for power management giving us consistency and portability. There is still work to be done, but it works rather well right now. I've been using it on my laptop for a while now, so that's not just theory.
A big piece of work that needs to be done is to add a Wayland system compositor. This is where things get tricky. LightDM is a Canonical project, and as such they will not be working on a Wayland compositor since they decided to part ways with the rest of the Free software ecosystem and create their own display system, Mir. One of our big questions was whether a Wayland compositor would be welcome.
Robert Ancell, the LightDM maintainer, attended last night's meeting which was extremely helpful. According to him, a Wayland backend would be welcome (though they won't write any of it) and there will be no hard dependencies on Mir in LightDM. This is reassuring, but means we need to trust the roadmap of Canonical a bit here and also means we'll be doing all the heavy lifting on the Wayland side. David has stepped up to do that work, however, which is also encouraging.
Due to LightDM being under Canonical's purview, contributing to it requires signing the Canonical CLA which is not acceptable to many developers (including myself) as it allows Canonical to take any and all code written that ends up in a Canonical owned asset and close it. This means that we won't really be able to contribute to core LightDM very effectively as a team. Some individuals may choose to do so, but several have already stated they won't, including those with the most experience with things like Wayland.
The fact that it is already widely used is a plus, however, as it means we may be able to share some efforts with others. This is particularly useful for system integration bits. For instance, Robert noted that Ubuntu will be working on logind support for LightDM. That said, some of our downstream distribution partners seem less than keen on supporting LightDM in their distributions.
So in summary: very featureful, relatively mature after three years of development, we already have a good amount of integration, but it carries risk due to community and commercial dynamics.
Contestent #3: SDDM
This young whipper-snapper is still wet behind the ears, as they say, and is still learning the ropes but she's fast and lean and sports a shiny approach to life. Let's say hello to SDDM!
This project is only three months old and as such is, by far, the youngest of the bunch. It also has the fewest features. However, with less than 2,200 lines of code it already provides the daemon/frontend duality with socket communication much as LightDM does and the user interface is written with QML. In fact, the entire thing is written in C++ using Qt and the code is very clean at this point. As with LightDM, it's memory footprint is more than reasonable.
It is an open, community developed project and has been picked up by the relatively new QML-based Maui desktop project. The use of C++, Qt, CMake and git make this a very familiar feeling to the code base for us Plasma hackers. The QML package structure is actually very similar to our own, and I understand that was not completely by coincidence. There is one main developer with two others who have made some contributions as well. This is fairly similar to the LightDM development profile, except that the contributors are not paid by the same companies to work on it.
As with LightDM and KDM, a Wayland compositor needs to be written for SDDM. It also needs to gain support for a large number of features it is currently missing, such as AccountsServices, guest accounts and a number of others. It does already support systemd and have some power management features.
The biggest concern I have is the youth of the project. Will it continue to be worked on and mantained? Will other projects also adopt it as it matures? Only time can tell. I am very keen to seen how SDDM develops over the next couple of months.
Conclusions
This is a difficult decision to make. KDM is not going to make the transition into a QML and Wayland world with us, despite it having served us well in the past. We need something to take its place, and we'd prefer not to start from scratch when there are good choices that already exist.
On the one hand we have the feature filled LightDM with three years of track record behind it, but which still needs work to make it do what we want, and which has a relatively large codebase that will be hard to contribute to. That said, David has already put a good amount of effort into the QML support for LightDM.
On the other hand we have a youthful, and thus largely unproven, SDDM which needs even more work than what we'd have to dedicate to LightDM but whose code base is very small, modern and uses familiar tools and which is developed openly. We won't need to do any QML work, but we will need more system integration features. With SDDM, there'd also be very limited (if any) opportunities to work with non-Qt/QML desktop projects.
If more projects interested in Wayland got involved with either LightDM or SDDM, that could tilt the scales as we would be able to share the compositor work with them. Personally, I'm torn between the open community and great code base of SDDM and the utility, maturity and wide usage of LightDM.
slashdot it
digg it
del.icio.us
Facebook
reddit
StumbleUpon
Twitter
