Posted on by Martin Flöser

Wayland improvements since Plasma 5.8 release

Two weeks have passed since the Plasma 5.8 release and our Wayland efforts have seen quite some improvements. Some changes went into Plasma 5.8 as bug fixes, some changes are only available in master for the next release. With this blog post I want to highlight what we have improved since Plasma 5.8.

Resize only borders

KWin’s server side decorations have a feature that one can resize the window in the shadow area. With the Breeze window decoration this is available if one uses the border size “No Side Borders” or “No Borders”. For Wayland we just had to adjust the input area of a window slightly and honor it when evaluating the mouse pointer movements.

Global Shortcut handling

We found a few bugs related to global shortcut triggering. There is some unexpected behavior for shortcut triggering in xkbcommon, which will be addressed in the next release by adding new API. For now we had to workaround it to support some shortcuts which no longer triggered. Of course for every kind of shortcut which did not trigger we added a test case so we can also in future ensure that this works once the new xkbcommon release is available. At the moment we are not aware of any not working global shortcuts on Wayland. If you hit one, please report a bug.

Support for Keyboard LEDs through libinput

KWin did not enable the LEDs for num lock, caps lock, etc. This was mostly because I don’t have any keyboard which has such LEDs – neither my desktop keyboard nor my two notebooks have any LEDs. So I just didn’t notice that this was missing. Once we got the bug report we looked into adding this. I want to take this as an example of the “obvious bug” one doesn’t report because it’s so obvious. But if one doesn’t have such hardware it’s not so obvious any more.

Relative pointer support

A feature we added for Plasma 5.9 is support for the relative pointer protocol.

Relative Pointer Events

The protocol is implemented in KWayland 5.28 and KWin is adjusted to support the relative pointer events as can be seen in the screenshot of the input debug console. This is a rather important protocol to support games on Wayland. We also plan to add pointer confinement for Plasma 5.9.

Move windows through the widget style

Our widget styles Breeze and Oxygen have a feature to move the window when clicking in empty areas. This is a feature which needs to interact with the windowing system directly as Qt doesn’t provide an abstraction for it. On X11 it uses the NETRootInfo::moveResizeRequest, on Wayland support for triggering a window move is built into the core protocol. But so far we were not able to provide the feature on Wayland as we just didn’t have enough information from QtWayland. For example we lacked access to the wl_shell_surface on which we have to trigger the move. So some time ago I added support to QtWayland that we can access the wl_shell_surface through the native interface. Now about a year later we can start to use it. To support this feature we need to create an own wl_seat and wl_pointer object and track the serial of pointer button press. This we can then pass to the move request on the ShellSurface. The change is not KWin specific at all and will work on all Wayland compositors.

Color scheme sync to decoration

A new feature we added in KWin 5.0 is the possibility to synchronize the color scheme from the window into the window decoration and the context menu on the decoration. On X11 this works through a property which our KStyle library sets. This was the best we had back in the early days of the 5.x series as Qt didn’t expose enough information. It has the disadvantage that the sync only works with QWidget based applications and only with widget styles inheriting KStyle. For Plasma 5.9 we improved that and brought the relevant code into plasma-integration. The restriction to QWidget is gone and it works now with all kind of windows by listening to the QPlatformSurfaceEvent. This very useful event which got added in Qt 5.5. It informs us when a native window is created for a QWindow. Thus we can add our own X11 properties on the native window directly after creation and before the window is mapped.

Custom color scheme support

While adjusting this code for X11 we also added the relevant bits for Wayland. We use the Qt Surface Extension protocol to pass a property to the server. That’s a small and neat addition the Qt devs did to allow communication between a Qt based client and a Qt based Wayland compositor. As one can see in the screenshot the color scheme now updates also for Wayland applications.

Window icons

Window icon handling in Wayland is different to X11. On X11 the icons are passed as pixmaps. That has a few disadvantages nowadays because the icons provided on the window might not have a high enough resolution to work well on high-dpi systems. The icon from the icon-theme though provides higher resolution. On Wayland there is no way to pass window icons around and the compositor takes the icon from the desktop file of the application. This works well unless we don’t have a desktop file. For such windows we now started to use a generic Wayland icon as the fallback, just like we use a generic X icon as fallback for X11 windows which don’t have an icon.

Proper icons for X windows in task manager

That’s an icon which one might have noticed when using a Plasma Wayland session as every Xwayland window only had the generic X icon in the task manager. The communication between KWin and the task manager also passes the icon name around and not pixmap data. This works well for everything which isn’t Xwayland where we normally just don’t have the name. For Plasma 5.9 we addressed this problem and extended our protocol to request pixmap data for a window icon which doesn’t have a name. Thus we are now able to also support Xwayland windows, which increases the useability of the system quite a lot.

Multi screen effect improvements

On Wayland several of our effects broke in a multi-screen setup. This is because rendering is different. On X11 all screens are rendered together in one rendering pass and we have one OpenGL window to render to. On Wayland we have one OpenGL window per screen and have one rendering pass per screen. That’s something our effects didn’t handle well and resulted in rendering issues. For Plasma 5.9 these issues are finally resolved.

Wobbly windows

One of the affected effects is Wobbly windows. A rather important effect given that this blog is subtitled “From the land of wobbly windows”. We experienced that in a multi-screen setup the effect was only active on one screen. If the window got moved to the other screen it completely vanished.

I was quite certain that this is not a problem with the effect itself, but rather with the way how we render. As we also saw other effects having rendering issues in multi-screen setups I was quite optimistic that fixing wobbly would fix many effects.

The investigation showed that the problem in fact was an incorrect area passed to glScissor due to the general changes in rendering explained above. Rendering on other screens got clipped away. With the proper change we got wobbly working and several other effects (Present Windows, Desktop Grid, Alt+Tab for example) without having to touch the effects at all.

Screenshot

With that knowledge in place we looked into fixing other effects. E.g. the screenshot effect which allows to save a screenshot in the tmp directory. A few example of screenshots taken with this effect can be seen in this blog post. The problem with this effect was that when taking a fullscreen shot over all screens only one got captured. The assumption here was that our glBlitFramebuffer code needs adjustment to be per output and with that we can now screenshot every screen individually or all screens combined.

Multi-screen shot with blur

Blur and Background Contrast

Related to that are the blur and background contrast effect as they also interact with the frame buffer, though don’t use the glBlitFramebuffer extension. With those effects one of the biggest problems was that the viewport got restored to a wrong value after unbinding the frame buffer object. Due to that the rendering got screwed up and we had severe rendering issues with blur on multi screen. These issues are now fixed as can be seen in the screenshot above: both screens are rendered correctly even with blur enable.

Panel improvements

Plasma’s panel got some improvements for Plasma 5.9. This started from bug reports about windows can cover not working and also auto-hide not working. Another example that it is important to report bugs.

Auto hiding panel

On X11 auto hiding panels use a custom protocol with KWin to indicate that they want to be restored if the mouse cursor touches the screen edge. It uses low level X11 code thus we also need a low level Wayland protocol for it. We extended our plasma shell protocol to expose auto hiding state and implemented it in both KWin and Plasma.

Search in widget explorer

We had a bug report that search in the widget explorer doesn’t work. The investigation showed that the reason for that is that the widget explorer is a panel window and we designed panels on Wayland so that they don’t take any keyboard focus. This is correct for the normal panel, but not for this special panel. We adjusted our protocol to provide an additional hint that the panel takes focus and implemented this in kwayland-integration in a way that the widget explorer gains focus without any adjustments to it.

KRunner as a panel

Of course there are more potential users for this new feature. One being KRunner. Once we had the code in place we decided to make KRunner a Panel on Wayland which brings us quite some improvements like it will be above other windows and on all desktops.

57 Replies to “Wayland improvements since Plasma 5.8 release”

  3. Awesome, especially dragging windows from empty areas!

    About Krunner I’m not sure I will like it as a panel, but mine is a strange use case: I have just 2 GB of RAM on my laptop, when I need some free RAM I close plasmashell and start apps with Krunner. I suppose Krunner as panel imply that plasmashell have to be running :-/ right?

    1. I suppose Krunner as panel imply that plasmashell have to be running :-/ right?

      Not at all. It’s just a window type – a hint to kwin that this window is to be treated as a panel. KWin doesn’t care whether the process is plasmashell or krunner, in fact KWin doesn’t even know that.

  4. I didn’t know about resizing windows with the shadows. That’s very cool, I removed the borders and still can resize them!
    Thanks Martin 🙂

  5. “this as an example of the “obvious bug” one doesn’t report because it’s so obvious” – there are a lot of bugs I would like to report but they are hard to reproduce or there is no way for me to give the info to reproduce the issue. These bugs overwhelm me and I give up and find workarounds or avoid KDE if the bug is blocking me from working in that environment.

    Examples:
    – My PC at home(Intel HD Graphics 530) uses KDE Neon Stable. Through different versions of Plasma(5.7.x, 5.8.x), the issue presents itself from time to time: the windows on the task manager bar(the bar that is on the bottom usually) don’t disappear/appear sometimes when applications are closed/started.
    You start an application, go to the bottom and try to click on the application and it opens something else or nothing at all(because it didn’t refresh the bar when the application opened/closed).
    This bug is very random(can appear a few times per day or every other week) and there is no way for me to reproduce it…
    I just do “Alt + F2” -> “killall plasmashell” -> “Alt + F2” -> “plasmashell”. It recovers after that…

    – KDE Neon Git + Wayland – doesn’t work in a virtual machines(tried in VMWare at home and at work), doesn’t resize(probably a VMWare Tools issue here), the mouse pointer shows one location but in reality it is a few pixels on the left(you can even see the hover effects when moving the mouse a few pixels to the right of the button) – I think this should be easy to reproduce…(it works at home and at work for me with VMWare).

    – I installed on the weekend KDE Neon Stable on an old laptop where older KDE was working perfectly fine(Intel Core 2 Duo with integrated graphics). On X11 it has some artifacts when you move the mouse, leaving trails of the mouse and cleaning them from time-to-time…
    I then installed KDE Neon Git. Same issue on X11…
    I then installed Wayland inside it. Surprisingly, it was working better on Wayland and the bug was not present any more. But, now every window I would open, would go outside the desktop, on some imaginary second screen which I didn’t have connected – I would go with the mouse outside the screen and with “Alt + Left-Click” would grab windows from there and drag them on my desktop…

    Again, there are a lot of bugs that are hard to report and this overwhelms. You know you cannot report “Task Manager Bar does not refresh sometimes” and expect this to be helpful, so you just give up…

    2. [quote]You know you cannot report “Task Manager Bar does not refresh sometimes” and expect this to be helpful[/quote]
      Of course you can! And you should. Maybe someone else has the same problem, and thinks the same way. If he/she recognizes your report, its more easy to just confirm it.
      And if not, the report can still be closed after some time.

      1. In fact I do experience that behavior too, and I’ve noticed that it happens with apps like games. I though it was already reported because it is obvious, but I guess it is not. And this post makes me realize how the small details may be very well bugs that no one reported because they are “too obvious”

  6. Hi Martin,

    Great work. Will these multi-screen changes fix an issue of panel flickering on the second screen too?

    Thanks

  7. Thanks. Highly, appreciated (both fixes and this blog). I guess most of the issues I noticed during the testing earlier should be resolved now. Well, I guess except for that tricky issue of windows not showing up when clicking on system tray.

  8. I would love working vsync *without* having to fiddle with some xorg settings first.

    Last time I checked, on intel (skylake) you cannot get vsync in kwin without settings TearFree. Note that according to “man intel”, TearFree does something the compositor is supposed to do.

    When using the binary nvidia driver the same happens. Depending on whether nvidia has once again broken or fixed their driver (current one in arch seems fine again), using anyone (or a combination) of __GL_YIELD=”USLEEP”, TripleBuffer xorg option or using ForceFullCompositionPipeline meta mode is needed.

    Note that I refuse to use nouveau (yet), simply because it either lacks performance or has no power-saving implemented, or lacks features I want.

    I just wish fiddling with any settings would be utterly unnecessary. And googling KWin vsync gives tons of people who regularly hit this on recent KWin. I wouldn’t mind testing code, I just cannot write it myself. I would report bugs, but anytime I look though bugzilla it is something either resolved long ago or “fixed” by any of the above options, which in my opinion *should not* be necessary.

    Otherwise I really love how KWin keeps improving and thanks for the great work.

      1. Let me make it Wayland then 😛

        How does wayland fare in regard to vsync? I know that one goal is that every frame shall be perfect. Are we there yet or has it always been that way? And how do XWayland and vsync go into this picture?

        Thanks

        1. vsync is irrelevant in wayland. wayland simply doesn’t need vsync; it’s tear free by design.

        2. Since I switched to Wayland I have not seen any tearing. Neither for Wayland nor for Xwayland windows. Rendering is synced. Applications can render at any frame rate they want, but there is also a good callback mechanism in place.

  9. Hello Martin,
    i wonder how you are going to handle full screen OpenGL applications (games) with WL.

    I loved the way you did it for X, but is it even possible to freeze “compositing” or anyway free the GPU when running games on Waylands?

    1. Yes, we are working on that. The idea is that we completely bypass the rendering an present the buffer provided by the application on a drm layer.

      1. Yes, please! With high-res displays extra full screen blits end up costing quite a bit more. Sounds like you have a good plan.

        This sounds like it’s going to be a fantastic release 🙂 Thanks for all of your hard work!

  11. Really nice to see the progress towards Wayland going at such a fast and steady pace.
    Thank you so much for your work Martin.

  12. Hello Martin,
    is screen rotation on your roadmap?
    I would also like to know what kind of pointing device you use. I use a trackball, touchpad and a touchscreen and none of them is really usable with libinput.

    1. is screen rotation on your roadmap?

      It is on our roudmap, yes.

      I would also like to know what kind of pointing device you use. I use a trackball, touchpad and a touchscreen and none of them is really usable with libinput.

      Trackball on main system, touchpad and touchscreen on notebook. Work fine for me, but I’m not someone who tweaks the settings. Never used the touchpad configuration module (neither on X nor on Wayland).

      1. I didn’t know about the new DBus interface and the possibility to enable tap-to-click functionality. It’s much better.

        I think about implementing a wheel button emulation to get scrolling for my trackball. Where would you suggest to do it? KWin/libinput or rather in the libinput itself?

        1. Never mind. I just discovered libinput_config_scroll_method, so it just needs to be supported by KWin/libinput.

  13. @leds: “Once we got the bug report we looked into adding this.”

    I didn’t care enough reporting it, since it “worked” and I don’t care for leds. Good to know you care, maybe I should report things like that.

    But.. Wow, a lot of progress for two weeks. Since nvc0 stopped freezing on me with recent kernel releases (4.4.24 and 4.7 up) I can finally test it… And I am very happy about that.

  15. I have a couple of questions:

    1. Under KDE 4, kglobalhotkeys misbehaves severely if you remap Caps Lock to Hyper and try to bind separate shortcuts to Super (WinKey) and Hyper. Is that included in your new set of test cases yet?

    (I think I’ve reported it, but it’s been so long that I can’t be sure and, if it was one of those ones that got closed for being “too old”, I just don’t have the time and energy to care anymore.)

    2. My keyboard has eye-searingly bright blue status LEDs and, rather than cover them with electrical tape, I like to use an X11 flaw (modifier state not synced between virtual keyboards) to trick X11 into reversing the state of the numlock light so it’s a glaring “You didn’t turn numlock back on, you fool! Fix it!” indicator.

    Given what I know about libinput’s goals, I’m going to assume that “feature” has been fixed under Wayland. How big a patchset would I have to maintain to get that under KDE+Wayland and which packages would I have to patch?

      1. I noticed the similarity too, but there are four big differences:

        1. I could just as easily cover up the LED with color-matched electrical tape as I did with the glaring blue LEDs on my case. It’d just be nice nice to get some use from the LED, since it’s there anyway.

        2. Unlike smartphone apps, Linux is a platform known for focusing on user choice and KDE is known for being the most customizable of the major desktop environments available on Linux.

        3. Even under X11, this isn’t really a “feature”. It’s more about using one bug to work around another bug (X11 refuses to honor user requests to manually set NumLock and CapsLock LEDs and/or detach them from the state of their associated modifiers).

        4. Unlike the users being lampooned in that xkcd comic, I have programming experience and I’m actually willing to rip out and reinvent pieces of my stack to get my way, rather than just running my mouth in reviews.

        For example, back before I finally gave KDE 4 it’s sixth or seventh chance to prove the claims that “no, really, this time it IS as stable and responsive as KDE 3.5.10”, I was running Lubuntu. When they removed the dconf key to opt out of “please reboot to update your kernel” nags, I deinstalled the GTK+ update notifier and wrote my own “quickest way to get something good enough” replacement using a mix of cron, shell script, zenity, urxvt, and apt-get.)

        Here’s the blog post (with screenshot) I wrote, in case you doubt me:
        http://blog.ssokolow.com/archives/2014/08/08/hacking-together-a-quick-update-notifier/

        1. I suppose you could just set to read only the LED control devices… I’m not sure if libinput uses those. I used to disable blinking on the WiFi LEDs on my old laptop.

          Or you can write the feature “Disable LEDs for this device” for Plasma.

          1. Possibly. The hard part would be finding the time to go through all the extra work to implement a selectable feature, properly bug test it, and get it accepted, rather than writing what I suspect would be a 2-3 line patch to libinput to invert the behaviour of the NumLock LED, build a custom deb, and then amend my crontab so more than just my nVidia drivers are watched for “manual intercession needed” updates.

            (I have my nVidia drivers pinned so they can’t update until it’s a convenient time to shut down my session and bring the kernel and userspace versions back into sync.)

    2. Under KDE 4, kglobalhotkeys misbehaves severely if you remap Caps Lock to Hyper and try to bind separate shortcuts to Super (WinKey) and Hyper. Is that included in your new set of test cases yet?

      I haven’t tested that yet, but I assume that is handled correctly. In general shortcut handling is closer to the keymap on Wayland, while on X11 it’s closer to the keys.

      How big a patchset would I have to maintain to get that under KDE+Wayland and which packages would I have to patch?

      A one-liner if you want to make it work for just you. kwin/src/libinput/connection.cpp – method Connection::updateLEDs you just need to invert the mask. If you want to make it to work for everybody (config option) it needs a little bit more work to actually expose the config option and then inverse the code. You are not the first one I hear to want that, so I’m not completely against it, although it will increase the complexity a little bit.

      1. Thanks. I know what I’ll be puttering around with as soon as Wayland support for the nVidia binary drivers gets sorted out.

  16. What about graphical tablets support, both on Wayland and X11? Is kcm_wacomtablet going to be revived? For now, I have to set up my tablet manually from command line in X, and I have no idea if that would work with Wayland.

    1. Graphical tablet support is on the todo list for Plasma 5.9. How much of it we get done I do not know – it’s a huge area of work.

      1. Might be an idea to talk to the Krita developers regarding graphics tablet support, IIRC they have written quite some code regarding those

  17. I’m running Neon on my laptop with the Nouveau drivers and I tried the Wayland session a couple of times. It’s getting better and better (plus I like the wobbely windows 🙂 ).

    On thing that is a bit annoying is that KWallet does not seem to work: after entering the password it shows an error with code -9 and asks for the password again. Am I the only one or is this known? I figured I’d ask here first before opening a bug report.

  18. Hallo Martin.
    You said:
    “Multi screen effect improvements
    On Wayland several of our effects broke in a multi-screen setup. This is because rendering is different. On X11 all screens are rendered together in one rendering pass and we have one OpenGL window to render to. On Wayland we have one OpenGL window per screen and have one rendering pass per screen. That’s something our effects didn’t handle well and resulted in rendering issues. For Plasma 5.9 these issues are finally resolved.”
    Does it mean, does it include different Wallpapers and independent plasmoids on every Virtual Desktop? I miss exactly both features (content of KDE 4.14.x) very, very much.
    Or, if not, when will these features adopted in Plasma 5 then?
    Thank you in advance.

    -Linuxfluesterer

    1. I didn’t write anything of virtual desktops or wallpapers. So I don’t understand how you can get the idea that this would be related.

      1. Hallo Martin.
        Maybe my mistake. I interpreted ‘screen’ as either real or virtual. And in another forum I heard something about that either wayland or qt5 makes it difficult to have independent virtual desktops. Anyway, do you know something about the features of individual wallpapers and plasmoids on virtual desktops will be implemented into plasma 5?
        Exactly because of missing these features I still work with a running KDE 4.14.10. Plasma 5 I have installed on an older laptop just only for testing which features are shipped with plasma 5. But I will change to plasma 5 as productive system, when individual desktops will be supported. Before, I see no need to change. In fact, beside that Korganizer is not updated yet (for Google calendar use, not by WEBDAV!) I don’t see any benefit in plasma 5.
        Thank you in advance.

        -Linuxfluesterer

        1. Hallo Martin.
          Es wäre wirklich klasse gewesen, wenn Du geantwortet hättest. Denn soweit ich gelesen habe, bist Du ja (Mit-)Entwickler von Plasma und gerade die unabhängigen virtuellen Bildschirme (Virtual Desktops) incl. unabhängiger Plasmoiden und Wallpapers fehlt doch sehr vielen KDE (4) – Anwendern.
          Trotzdem, danke für die erste Antwort.
          -Linuxfluesterer

          1. Mein Blog ist nicht der richtige Ort für solche Dinge. Es kann halt mal passieren, dass ich nicht zum Antworten komme. In dem Fall kann ich wirklich nichts dazu sagen, da ich an der Entwicklung der virtuellen Desktops in Plasma nicht beteiligt bin. Ich arbeite hauptsächlich am Window Manager.

  19. Hi Martin,

    First sorry for my bad english.

    I tired the current Neon git-unstable Wayland image 20170110. My question is why is there a “Tearing prevention (“vsync”)” option in the compositor settings? I thought Wayland is tear-free by design.

Comments are closed.