Last month our Wayland efforts made a huge step forward. In KWin we are now at a state where I think the big underlying work is finished, we entered the finishing line of the KWin Wayland porting. The whole system though still needs a little bit more work.
The big remaining task which I worked on last month was geometry handling. That is simplified: moving and resizing windows. Sounds relatively easy, but isn’t. Moving and resizing windows or in general the geometry handling is one of the core aspects of a window manager. It’s where our expertise is, the code which makes KWin such a good window manager. Naturally we don’t want to throw that code out and want to reuse it in a Wayland world.
And that meant: refactoring. The big problem here was that the code in question is also highly X11 specific. Examples are: the sync protocol for synced resizing, window gravity handling, various X11 specific quirks for moving X11 window moving smooth (e.g. only update at end of move if compositing is active, direct updates if not active).
The task was now to separate the X11 specific geometry handling from generic geometry handling so that it can support both Wayland and X11 windows. With this now in place all the geometry handling works also for Wayland windows. This includes move/resize through the alt+f3 menu, but also triggered from the window itself. During move/resize the quick tiling areas are of course triggered correctly, show the outline and snap to the area if released. Resizing is automatically synced to the speed the client supports and that also in a much better way than on X11 (yay for Wayland and double-buffered state!). During move/resize the windows snap to screen borders and other windows.
Unfortunately our checks to ensure that the window titlebar is not moved outside the visible area doesn’t work, because of client side decorations. Yay, everything is awesome! Have I mentioned that client side decorations are a stupid idea because it breaks useful stuff? No, cannot be. Related to that: QtWayland enters move mode if you click the title bar to activate the window. Of course there should be a delay which KWin implements for it’s decorations. After all we have more than 15 years of experience in doing window decorations. Yay, client side decos! Given control to the application! Let’s leave them in charge of window management, what could go wrong? Wohoo! Totally awesome! Broken window management! That’s the way to go! Of course that could be fixed in Qt, but well it doesn’t fix the problem. We have seen this in Chromium years ago, we even had to adjust our quick tiling/maximization behavior because of it. Another fun fact: QtWayland deco has a minimize button which does nothing because it’s not supported in wl_shell protocol. Have I mentioned that client side decos are awesome?
All right, all right, I’ll end the sarcasm mode now. Our geometry handling has a few more very handy features like window packing: you can configure a shortcut to move the window left (or other direction) and it will move to the next window or the screen border. Similar we support growing or shrinking the window to the next window. I was hardly aware of that feature before doing the refactoring, so I thought I should point it out. It can be used from scripting, so should be useful for ideas like poor man tiling or resizing multiple quick tiled windows at the same time. As a nice addition this code is now covered by auto tests.
So with geometry handling in place it’s possible to do real testing and one of my systems (my notebook) migrated from X11 to Wayland. Actually I have been using Wayland on that system already for watching videos since April as it gives tear-free rendering. A clear plus when watching videos.
And this gives us already the outlook for what we will see in the November update: I’ll focus on stabilizing the current state of Plasma/Wayland and fix bugs, fix bugs and fix bugs. My aim is to have a useable early-adopters version ready for the Plasma 5.5 release. It’s looking good, so I’m confident that we will reach that state.
For those of us that want to be early adapters, what kind of GPU do we need to have. I have a fairly new AMD card, which I am guessing will not make the cut, or will it ?
Thanks for all your great work in porting KWin to Wayland
I’m using Intel based hardware and haven’t tested with AMD yet. I guess radeon driver should work. No idea about the thing which used to be Catalyst 🙂 Given the shared driver architecture it might also just work.
The new Catalyst driver style is not finished yet, current Catalyst still uses the fglrx kernel driver and x.org DDX.
Open source radeon driver works perfectly in Wayland.
My laptop actually has a really nasty rendering bug under Radeon – keep meaning to report it, but keep getting distracted. It only manifests under DRM, and only with KWIN_COMPOSE=O2 (Q works, all other values hang).
What happens looks almost as if the scan lines are the wrong length – individual rows of pixels are offset relative to the one above them, resulting in output that is both completely mangled, and yet recognizable – theres a blobbish area at the top that can be recognized as a “titlebar”, moving the mouse causes disjointed updates but when they overlap with the “titlebar” dragging causes changes that, if you cross your eyes, make sense.
Colors are correct, which is what let me recognize what happened in the first place.
do you have wobbly windows activated?
I do not.
I am on Mesa 11.0.1, libdrm 2.4.65, Wayland 1.8.1, and KWin git 8e17059be76d05cc2c883746827a234bc6c27a58
My config is set to use OpenGL 3.1/EGL in System Settings, accurate scaling, auto tearing prevention, only shown thumbnails, and color correction, with these effects active:
Zoom
BG contrast (dotted check)
Blur (dotted check)
Fade
Login
Logout
Maximize
Screen Edge
Sliding Popups
Translucency
Window Aperture
Minimize Animation
Dialog Parent
Slide
Desktop Grid
Flip Switch
Present Windows
Just tested disabling color correction _and_ all effects; no change.
Going by my experience with the Gnome/Wayland example in current Fedora, any GPU with decent open drivers should work fine. I’m running onboard graphics from an AMD Kaveri-generation CPU, and it’s working fine and stable.
Does this have any impact on how geometries work from scripts? Specifically, does it change anything about https://bugs.kde.org/show_bug.cgi?id=341195?
Actually not much. I haven’t looked into the scripting story on Wayland yet. Though for the specific bug report: at least QtWayland windows cannot be resized to be smaller than their min size (empirical testing with resizing kwrite :-P). There is no real min size in wl_shell, so we don’t have that information.
Sarcasm aside, I’d like to remind that I and everyone I know of thinks that wl_shell sucks. It was a stop-gap measure to get Wayland on desktop bootstrapped, so that we could have *something* from apps appearing on screen at all. We need something better, something that kicks wl_shell into oblivion by providing a superior interface to enable proper window management.
Chipping in with Pekka here, I think the solution to at least some of your issues is to get xdg_shell stabilized and merged into the wayland repo. It does provide a minimize and it also provides a min/max if I recall correctly.
Client-side decorations are a whole other ball of wax…
I only talked about the problems with client side deco. My critic is not that wl_shell doesn’t provide minimize, but that clients do stupid things like providing a non functional button. No xdg_shell can solve that as long as client side decos are the wanted default. And I don’t have any hope there. I provided feedback on what we need, but it got from my perspective either ignored or blocked.
First, I forgot to congratulate you on the achievement. Congratulations! 🙂
Sorry, I’m not sure I understand the “non functional button” issue. If we have protocol that adds support for that button, then that button will work, whether it’s CSD or SSD or the compositor issuing drawing commands to the clients or something completely different. Even if that functionality was not supported, then the clients would know it is not supported, and in case of CSD they would not draw a non-functional button.
For the record, I have personally NAK’d all efforts to stabilize xdg-shell protocol so far on the grounds that I believe it cannot be done without the KDE team taking part on the design and agreeing on it. I think this is a big reason why xdg-shell protocol development has been dead for several months. I am waiting for the KDE team to take interest and find the time to start working with the other DE teams. This protocol is something that “Wayland upstream” cannot design on behalf of the DEs, and yet it is crucial for having apps work at all across DEs.
If I remember correctly, I haven’t seen a single email on the wayland-devel list from KDE people on the shell protocol issue in 2015. People could be discussing it elsewhere (and maybe they should, to keep SNR good), but it feels like it is not happening.
As I am not part of any major DE camp, is there anything more I could do the mediate this problem?
What alternative do we have if we cannot agree on a common way to put windows on screen? wl_shell is not a solution.
Thanks 🙂
ah my comment on that was absolutely not about the protocol, but about clients doing stupid things. In this case Qt knows that minimize doesn’t work (it’s commented like that) and nevertheless they add the button. That’s what I dislike. It’s not about the protocol. Not having a minimize button would be fine, having a minimize button which works would be fine, having a minimize button which shows a disabled state would be fine. Having a button which you can click but doesn’t do anything is not fine. Has nothing to do with Wayland, but all with why I dislike the idea of allowing clients to do things like that. They will get it wrong, not even Qt gets it right.
Sorry that I haven’t commented on the xdg shell spec for a while. I had been rather busy with other Wayland related stuff and I must admit that I’m not looking forward to the discussion about xdg_shell. I will have to bring up the point about decorations again (because I think it’s quite needed), but I’m afraid of that. The discussion has worn me out, I’m a little bit burnt out over it. Main reason is that we have lots of breakage on X11 due to GTK and zero movement on fixing the issues. This frustrated me extremely and I am afraid of raising this issue in a Wayland world again and having a feeling of running against brick walls. Sorry about that. It shouldn’t be an excuse why I didn’t participate in the discussion.
Anyway: let’s look forward. I’m no longer convinced that xdg_shell is the way forward. I don’t think we can have one protocol to rule all DEs. We tried that with NETWM and well look at the spec. It’s not precise, it’s contradicting, it provides multiple solutions to the same problem, just to suit everyone. That’s clearly not what we want! But just the points about decorations show that we won’t find a common ground. If GTK+ wants client side decos: that’s fine. If Plasma wants server side decos: that’s also fine. We just will never get a protocol which can serve both.
So instead I think what’s needed is something we also did (on KDE side) for NETWM: add lots of atomic extensions. One protocol for state handling. One protocol for exchanging whether server side decos should be used, etc. etc. Each compositor could very easily announce support for it, each toolkit as well. All that’s needed is that compositors and toolkits can handle the lack of an extension gracefully.
And then wl_shell doesn’t look that bad anymore. I’m really impressed how far we got with just wl_shell + Qt’s surface extension protocol. It gives us quite a good working system. Yeah not all features like on X11, but a pretty decent system.
So instead of trying the one huge big thing: many multiple small. Each of the interfaces would be easier to get standardized. We could have contradicting interfaces, etc. etc.
Thanks Martin, that actually is progress on the matter! Proposing to do a bunch of well-defined extensions for specific topics is very Wayland’y in my opinion. I hope that will lead to a good number of them ending up universally shared eventually. But how will you avoid ending up with several overlapping and possibly conflicting extensions. How does a client pick which path to take if the compositor offers multiple for interoperability’s sake. That will be interesting to see.
It might be better to gather a cross-DE group and discuss things in private first, to avoid heated discussion. When there is a tangible proposal, it will be much easier to discuss in public, I believe.
PS. wl_shell really is bad. It does not work without a keyboard. 🙂
That is a good question. From X11 I think it’s not much or a problem. First of all I doubt that compositors would implement conflicting extensions. At least for NETWM KWin never implemented the conflicting parts. But yeah, it’s an interesting part to think about.
Yeah, sounds like a good idea. Mailing list is always problematic for such kind of things.
Hmm, we got it working reasonably well in our phone project (which implies no keyboard).
wl_shell uses keyboard focus to denote the active window. If there is no wl_keyboard, no window can be signalled active. Of course, if you don’t need the concept of active in the client side, you wouldn’t notice. 🙂
We run into that one and thought it’s a Qt bug. For KWin it doesn’t really matter as we have internally traditionally bound the concept of active window to keyboard focus. So all that was needed was taking that we have a keyboard. Which is not completely wrong given that phones have hardware buttons.
+1 on CSD is stupid 🙂
Decorations belong to the WM/DE – improving them (e.g. to allow putting tabs into the decoration) is certainly a good thing, but “improving” by taking them away from the WM/DE is evil!
p.s.: congrats on the progress! Sounds very awesome. Will wait for the November update and then test 🙂