screen config victory!

kscreen wayland backend in action

kscreen wayland backend in action

That moment when the application “just works” after all your unit tests pass…

A really nice experience after working on these low-level bits 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.


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.

8 Responses to “screen config victory!”

  1. Richard says:


  2. isabelle says:

    Excellent work ! it is great to see this is working now :)

    I’d vote for the “configuration profiles” feature which is an excellent idea and something I’m missing everyday when I switch from my office where my external monitor is on the right side, and home where the external monitor is on the left side…

    Thanks for the good work !

    • Wolfgang says:

      I agree, configuration profiles would be really great! I also change places regularly with my laptop where the external monitor is at some places left, and at others right (university/student dorm/parent’s house in my case).

      Just to entertain the other blog readers, I will tell you my current ‘solution’:
      A hotkey triggers the parsing of lsusb, checks which mouse is plugged in, and calls xrandr accordingly.

  3. Joe says:

    How would per-display scaling behave, when moving a window halfway from one screen to another?

    Also, David Edmundson explained why there’s only integer precision in scaling here: Do you disagree with his argument? I’m using 160 DPI displays and would be very glad if decimal precision were possible.

    Thank you so much!

  4. Rezza says:

    per-display scaling – yes please! And you’ll be my hero :).

  5. Pascal d'Hermilly says:

    Super cool with test-driven development – that will remove the need of sooo many small bug fixes as people hit them.

    About the screenshot – why does 1280×800 appear twice on the resolution slider?
    If the the title string of the configuration module was changed from “Manage and configure monitors and displays” to “Screen management” it would make the module lighter.
    For displays that has variable brightness it might be a good idea to write: Brightness is controlled in the power management settings.

    Super great work!

  6. smurfy says:

    Great to hear. Thanks for your good work!

    I would vote for per-display scaling. It´s not very comfortable to work with an 13″ 2560×1440 laptop connected to an external 24″ 1920×1200 display. If its looking good on the small laptop screen, then its way too big on the external screen. And if its ok on the external screen, then its way too small on the laptop screen.

  7. lika says:

    Awesome ! Everyone develops visual impairment with age so better scaling and HiDPI benefit everyone. Too often developers don’t think about the needs of an ageing population which they will join.