This weekend I read a blog post by Robert Ancell from Canonical claiming that the display server doesn’t matter . To quote the direct message:
The result of this is the display server doesn’t matter much to applications because we have pretty good toolkits that already hide all this information from us.
Now I don’t know how to put it, the best description is that I’m shocked that Canonical is still not seeing the problems they created by having multiple display servers. I do not know how much experience Robert has with making applications work with multiple display servers, but I at least have this experience as shown in my blog post on making KF5 not crash on Wayland. Granted in this blog post I write that “basically if your application compiles on frameworks it will run on Wayland out of the box”. But that is a strong simplification of the issues which can be present.
With this blog post I will prove Robert’s claim that the display server doesn’t matter due to the toolkit wrong by contradiction. I could just stop here, because I already wrote that KF5 applications were crashing on Wayland prior to me starting to fix these issues. If the toolkit would just abstract away all the display server differences our applications libraries would not have crashed.
Also the assumption that the toolkit behaves the same is just wrong. One of the issues I fixed was Qt returning a nullptr from QClipboard::mimeData on platform Wayland while it returned a valid pointer on all other platforms. It’s obviously an application bug but the documentation doesn’t say that there could be nullptr returned or not. There can be hundreds or thousands of such small behavior differences. An application developer is not able to ensure that the application is working correctly on a distro-specific display server. If the application developer recieves a crash report for such an issue, the developer cannot reproduce the issue – not even on running the same distro with another DE – cannot write a failing unit test, cannot integrate it into the CI system. The most sane thing he could do is declaring that proprietary display server as unsupported. And this should show the problem: each developer will see issues caused by Mir – it doesn’t matter whether it’s in the toolkit, application libraries or in the application itself. Thus an application developer will have to care about the display server. The applications will have to decide whether they want to support Ubuntu.
Another example is different behavior. Look at this screenshot:
 |
| Aus Weston |
This is the KColorDialog running on Wayland and when I click the pick color button nothing happens and the debug output just says: “This plugin does not support grabbing the keyboard”. It uses QWidget::grabKeyboard – functionality provided by the toolkit. Again the documentation does not tell that it’s not supported on all platforms, it also doesn’t offer API hooks to figure out whether grab is supported. What will be a possible fix for this?
#if Q_OS_LINUX
if (!QX11Info::isPlatformX11()) {
colorPickButton->hide();
}
#endif
We just hide the button if we are building for Linux but are not on X11. Why is that wrong? Well what if other platforms still support it. So a better way?
#if Q_OS_LINUX
if (QGuiApplication::platformName().toLower().contains(QStringLiteral("wayland"))) {
colorPickButton->hide();
}
#endif
It’s better, it only hides it for Wayland. But what if the same feature is also not supported on Mir? How should a developer find out to fix that problem properly? How does a developer figure out what the platformName for Mir is? The documentation doesn’t know anything about Mir, the Qt sources (yes I have them on my system) don’t know anything about it. How long will it take till a user reports that the button is broken? Will the user tell that it’s Mir and not a normal system? After all our bug reporting tool reports “Ubuntu” for both Ubuntu and Kubuntu. And on Kubuntu, which the dev might be running, it’s working just fine.
Another example from a patch I prepared to fix an issue:
#if HAVE_X11
d->display = qgetenv("DISPLAY");
+ if (d->display.isEmpty()) {
+ // maybe we are on Wayland?
+ d->display = qgetenv("WAYLAND_DISPLAY");
+ if (!d->display.isEmpty()) {
+ // don't go into the xauth code path
+ return;
+ }
+ }
#else
Now will that code work with Mir given the way it is written? Obviously not. Could I have fixed it? Obviously not, because I have no idea whether Mir has a system like these env variables. What will happen if someone tries to fix it for Mir? I expect the maintainers to tell that this doesn’t scale and needs to be reworked. For two it’s a solution to just test one after the other, but with three systems it doesn’t scale any more. It becomes too complex. So yes the maintainer of this application library has to care about the fact that there are multiple Display Servers.
In summary: Canonical created a huge problem by introducing another Display Server and it’s affecting all of us and they are still in denial state. It’s not a simple the toolkit will solve it. It can cause issues everywhere and that affects the development and maintenance costs of all applications. My recommendation to application developers is to never accept patches for this mess Canonical created. If they want that fixed, they should do it in their downstream patches. Distro specific problems need to be fixed in the distros. I certainly will not accept patches for the frameworks and applications I maintain. This is not for political reasons as it’s so often claimed, but for technical, because I cannot test the patches (Mir not available on Debian) and our CI system cannot build it.
