Posted on by Martin Flöser

KWin/X11 is feature frozen

Yesterday the KDE Community released the Beta for Plasma 5.12 LTS. With that release the feature freeze for 5.12 is in place and also an eternal feature freeze for KWin/X11. To quote the release announcement: “5.12 is the last release which sees feature development in KWin on X11. With 5.13 onwards only new features relevant to Wayland are going to be added.” This raised quite some questions, concerns and misunderstandings in the social networks. With this blog post I try to address those question and explain why this change in policy is done.

Is KWin/X11 still maintained?

Yes! We are just in the process of releasing an LTS. Of course KWin is fully maintained in the LTS life time. While in 5.8 only X11 was maintained, now we are able to offer maintenance for both X11 and Wayland. For the maintenance we do not differentiate between windowing systems.

Will X11 bugs still be fixed?

As X11 is under maintenance, I expect bugs to still get fixed.

Does this mean that in 5.13 X11 will be unmaintained?

We are going to forward port bug fixes from the 5.12 branch to master. Thus any release after 5.12 will get all bug fixes from 5.12. Given that I would say 5.13 will also be maintained on X11.

Does this mean that in the next LTS X11 will be unmaintained?

We will decide when the time comes. Currently I do not expect that we would drop maintenance.

Does this mean Plasma 5.13 will default to Wayland?

This is about feature freeze for X11. Whether Wayland will be the default or not is completely unrelated to this.

Will X11 users not get any new features in KWin?

Of course there will be new features! Most functionality in KWin is independent of the windowing system. Any improvement to those areas benefit Wayland and X11 users. Currently we have a few improvements in the pipeline, for example tooltips on decoration buttons, improved blur effect, a rework of slide desktop effect, improvements to the cube effect and a few more. All of them will be available to both X11 and Wayland users.

How do you decide whether it’s an X11 only feature?

In the case of KWin this is very simple. There are areas in our code structure which are only get pulled in if run on X11, other areas are marked in an if (x11) section. If the new feature touches this code, it’s probably not going to be added.

Does this feature freeze also apply to other KDE software?

No, but personally I would recommend any maintainer to apply a similar feature freeze. I personally will not help developing any X11 specific feature any more and resigned as maintainer of various X11 specific frameworks this week.

What are you going to do if someone present a feature for X11?

It won’t be merged.

But why?

This requires a little bit more explanation. I had a look at the most prominent issues we had over the last years. Where are our stability problems, where are our quality problems, what costs most development time? I observed that it was always in new features specific to X11. Very often even for features we added to Wayland without causing problems.

So I started to look into why that’s so. The obvious answer that we don’t get bugs for Wayland because nobody uses is, is not the case. We get many bug reports for Wayland and many users are nowadays running Wayland. So the reason must be somewhere else.

On Wayland we are able to test the code. Let’s take an example: we get input events through libinput. For this we have unit tests through mocking. Thus we can automate the testing of the lowest layer. From libinput events are sent into KWin core through an internal API and that we can also use in the integration tests. So we can simulate everything from the point where libinput events would hit KWin core. We can test this properly, we know that we get all events (because KWin is the display manager) and we can test every aspect. We can lock the screen and verify how it works, we can make applications grab the pointer or keyboard and test this. We can invoke global shortcuts, etc. etc. It’s all just as if we get the events through libinput. The quality of these new areas in KWin feels really good.

A few weeks ago some commits I did hit the Linux media about KWin/Wayland without X11 starting too fast and due to that causing bugs. These issues were found through our test suite, before any user would ever be exposed to them.

What we did in the past was taking these new features and bring them to X11. But there we cannot test. There is no way on X11 to e.g. fake a touch screen. On X11 we cannot test how this behaves if we lock the screen or used Alt+Tab. We can write the code and manually test it. Hey it works, awesome! But that was mostly not the case. There were corner cases which caused trouble. And to this comes that the main devs run Wayland instead of X11. If features break they are not exposed to the bugs.

Could you give some examples of things that broke?

Sure! The first feature we backported to X11 was “modifier only shortcut”. We spent months fixing the fallout because of X11 weirdness. Another feature backported was panels on shared screen edges. It worked great for Wayland, but on X11 some corner cases were overseen and caused issues, which affected our users and required time to fix. We backported the touch screen swipe gesture on X11 which was a mess. On X11 touch screens are also mouse events, that made it difficult and created many corner cases.

The problem is not adding the feature. The problem is fixing the bugs created by the new features.

But if a new foo requires adjustments?

KWin won’t be adjusted to any new requirements in the XServer, Mesa, input stack, proprietary drivers, etc. If something breaks it’s the fault of those components which broke it.

91 Replies to “KWin/X11 is feature frozen”

  1. A bit of the cruel truth:
    I think you should not underestimate how many users do not use Wayland(in combination with KWin) and that’s why bugs are not reported.

    My personal experience:
    Initially I had only Intel with integrated graphics – Plasma on Wayland worked but it was filled with bugs(no HighDPI, window frames freezing in place after being closed, etc…) – I did not report these because I thought that the issues are so obvious and my hardware setup is so simple that there is no way the developers don’t see this too. I decided not to spam the developers with issues for which I can offer a lot less information than what they already know.
    I just switched back to X11 because I considered the software to be in an early alpha stage(that was when KDE neon made it easy to install `plasma-workspace-wayland`).

    Meanwhile I needed to work with Vulkan and the Intel drivers support only very old APIs… I went with the obvious and bought an Nvidia graphics card – now the Wayland support is zero, zilch, nada, nil, black screen.

    Since most modern PCs and Laptops come with Nvidia graphics, I am not surprised not many use it and report bugs.

    Taking into consideration that the X11 version crashes a few times per day(depending on how many times you open new windows) with Nvidia drivers(open-source or not – on Tumbleweed and neon), I don’t think you see All those reports either – that’s what a Linux user is accustomed to, you just do your daily dance with:
    – Ctrl + Alt + F1 -> sudo systemctl restart sddm
    – With Intel-only, was enough to do: Alt + F2 -> killall plasmashell -> Alt + F2 -> plasmashell

    1. Taking into consideration that the X11 version crashes a few times per day(depending on how many times you open new windows) with Nvidia drivers(open-source or not – on Tumbleweed and neon), I don’t think you see All those reports either

      You mean bugs like this: https://bugs.kde.org/show_bug.cgi?id=388767

      Yes, I see them, we get hundreds.

      I think you can trust that I have a fair understanding of whether bugs are getting reported or not.

    2. I wouldn’t use Neon for any machine. It falls apart really quick. Manjaro, OpenSuse and Kubuntu 18.04 have the best KDE experiances so far. And if you get this trouble in any of them on Intel, its really hard to believe. 2 notebooks that use Intel iGPU only work all the time and noone complained about it, i’ve seen no trouble either. 2 PCs with AMD graphics HD5770 and HD7870 on OSS drivers, and i see no trouble in either one. The problem is Nvidia.
      Kwin isn’t a proprietary game, there is no need to include specific workarounds inside of it. There is no need to write the code by Nvidia OpenGL guidebook, they’re known to not give a damn about standart.

      1. guessi,

        I believe you need to be more specific here as there are two editions for KDE Neon. There is the “User Edition” and the “Developer Editon.” The later being the most unstable of the two. I’ve found very little to fault KDE Neon “User Edition” and run it daily on a Dell N5010 Inpiron laptop without issue. This Inspiron has only Intel CPU and graphics. Other components vary (Broadcom wireless, and such). I have loaded the specifics to run Wayland and found it just too buggy to run on a daily basis. The Dev’s are working on this diligently to get KDE off Xorg for many reasons.

  2. Seeing as I agreed with most of your decisions regarding kwin and also seeing all the work that has been put into it I am not to worried about X11 going out of maintenance which is good.

    For myself I am currently not able to switch to wayland since it is still missing color management support which as a bit of a (hobby) photographer is rather important to me, sadly it seems this won’t be added anytime soon (last few discussion on the wayland mailing list ended in a stalemate between CMS developers and wayland developers AFAICT)

    1. stalemate between CMS developers and wayland developers AFAICT

      Having discussed with CMS developers in the past I can totally see this happening. From our side there is not much we can do. It just doesn’t belong into the compositor (something I tried to explain years ago to the CMS devs). Only applications can know which part needs to be color corrected. So yeah, the situation is not satisfying.

      1. Being the CMS developer mentioned, let me say that it’s not true that there is no Wayland solution possible – there are technical paths that would allow the application to hand color mapping to Wayland, so that the application can remain ignorant of which display the pixels end up on, but it is not simple, since it has to provide the same range of color transformation capabilities an application has available to it if it is not to be a step backwards. The other issues go to sharing the displays color profiles, and controlling graphics card per channel calibration curves. These are facilities that X11 currently provides standard API’s for, and the (as I interpret it) Wayland developers say is not something they want in Wayland since it is contrary to the purity of their vision, and to “go add that somewhere else”. But replacing one set of standard API’s with a hodge-podge of system/compositor dependent ones is not something color management application writers see as a step forward either, and would certainly make Linux+Wayland a very undesirable platform for Color critical applications and tools compared to Linux+X11, MSWindows or OS X.
        A Wayland extension is a way of fixing all this, even if it ends up something that is never officially accepted into Wayland, but just adopted by all compositors that wants to support color management.
        Currently it looks like anyone who uses serious color management on Linux, is stuck with needing a (real) X11 server.

      2. Under X11 no compositor support works perfectly fine since external programs can load a video card lut (often stored in the VCGT of an ICC profile) and programs can query the X server on which monitor they are running (since even 2 “identical” monitors might not be that identical color wise). Neither of which is as far as I know possible on wayland.

        In the future I expect this is going to get worse with “HDR” screens becoming more available to consumers (10+bit output with increased contrast and larger gamuts) while most applications will probably not be updated to support that (since fully supporting that only makes sense for image/video viewers), in which case some minimal color conversion support will be needed in the compositor and in that case there is the problem on how to give applications that do need full color control (image/video editors) that control.

        In the end I think that to get full color management on wayland both the compositor and the applications need to support it, how much needs to be in either is of course an open question. For example only setting VCGT + monitor id is fine for color managed apps but might leave other stuff not looking great on future “HDR” monitors, doing more might make non-color managed apps look better but gives a headache to color managed ones.

  4. This means wayland is stepping up. Decision supported by me.

    Maybe one concern: I’ve been using it with dual monitor setup with one monitor being hidpi, the other not. Let’s just say it isn’t ready for prime time yet in 5.11. If we assume that wayland will cause issues, would it be possible to have different release cycle regarding kwin because waiting several months for release can cost nerves?

      1. honestly, i did try running neon git-unstable for a few weeks, maybe even more than a month (cant really remember). wayland session wouldn’t start at all, so i went back to neon user (i’m using amd graphics with opensource driver).

        somebody below mentioned remoting. do you know is there something going on in this area with plasma?

  5. Bad decision. Wayland is a joke which still doesn’t have a decent remoting story. X11 is still the way to go. 🙁

  6. While I can understand you frustration with Nvidia, the amount of crash reports you’re getting just shows how big a user-base that is. Even if it’s not job, for the sake of the KDE project, I would try to improve the situation.

    1. There is simply nothing we can do. I cannot reproduce the problem and the backtraces are incomplete and missing debug symbols. We even lack steps to reproduce. Sure I can contact NVIDIA, but then what? They ask me how to reproduce and I answer “I don’t know”. They ask me to test things and I tell them “I cannot”. That would be a waste of my and NVIDIA’s time. Affected users need to report to NVIDIA, so that NVIDIA can fix. We cannot. The driver is proprietary. That’s the cost NVIDIA users have to pay.

            1. There are multiple reasons. In the past I used to have several cards with the idea of switching them out and testing on every of them. In practice I never did. The effort to get out the screwdriver, install the card, switch drivers were so high, that I never did it. Then I also realized it’s totally pointless if I would do so. There are too many cards, it’s not just the three vendors, they have different hardware generations, different driver generations. The matrix gets easily to 60 different cards, in the case of Intel it would mean different mainboards or complete systems. That makes it an unreasonable task to try to test it. Yes, it needs to be tested, but it cannot be tested by one developer in his spare time. That’s a full time job. So if I would do that, I would not be able to do anything else.

              So I decided to not accept any hardware as it’s pointless. With regards of NVIDIA the situation is also that I run Wayland. Accepting an NVIDIA card to test with the proprietary driver is absolutely useless for me. NVIDIA doesn’t support gbm, I cannot use it. And no, I’m not going back to X11 to test NVIDIA. I do my X11 testing on my notebook and it’s rather difficult to install a graphics card into a notebook ;-). My desktop system is Wayland only for – it feels like ages. I don’t even know how to start my development setup into X11 anymore and I’m not joking about that.

              Also I don’t want to be in any kind of debt to any vendor. Look at the comments here, now imagine I would have accepted hardware donation and not fixed NVIDIA specific bugs? See the anger here by the commenters. No, I don’t want to be exposed to that.

              I decide what I do in my spare time. I don’t want to do any driver testing, be it Intel, AMD or NVIDIA. No, I don’t want any hardware.

              The KDE community is larger than me. Just because I don’t do it and I don’t accept hardware donations doesn’t mean other KDE devs won’t do it.

              1. > There are too many cards, it’s not just the three vendors, they have different hardware generations, different driver generations. The matrix gets easily to 60 different cards, in the case of Intel it would mean different mainboards or complete systems.

                I think you make this more complicated than it is: only two setups – Mesa+Wayland and Nvidia+X11 – would cover 99% of all cases, when it’s purely a software/userspace bug. Hardware specfic bugs get also debugged by the GNOME developers and Nvidia themselfs, so there is a shared work load.

                  1. What are the numbers? What % of bug reports are due to graphics card model specific bugs and what % due to bugs in the common/shared driver code?

                    2. > We have bugs specific to Quadro.

                      That was not my question.

                      At the moment there are 101 open bugs filed against kwin that contain the word “nvidia” and 10 that contain the word “quadro”. So it’s 9,9%.

              4. hardware testing is precisely what I did for a short decade and the reason was that I had access to a huge inventory of cards that had been removed from machines that were traded in the great migration from i386. And yes, even then it required, eventually, a spreadsheet to keep track of the matrix of the hardware versus the various ways that the software could be enabled. And yes, it turned into a full time job, but since I also had access to the “motherboards” that were changed out during the great migration of hardware into South America, I housed them in racks which were supplied power from a single supply with stepper and fed just a few monitors. Ahhhh the halcyon days… 🙂

          2. So you actively refuse to test what hundreds of your users use, based on, I assume, ideological reasons.

            I don’t think that’s terribly nice towards the users, and I shall remember this whenever you try to put the blame on nvidia.

            1. I also don’t test on AMD, neither on Intel except the one chip I have. So what exactly is the problem ?

            2. So you think that NVidia should not support their paying customers by providing working drivers?

              KDE has no paying customers. It’s a non-profit, not a multi-billion dollar company like NVidia. Why should KDE be the party to debug NVidia hardware and drivers?

          3. Hello martin
            Your efforts have always been wonderful
            But sometimes you forget a large part of the user community

          4. So, from what I’m reading, the short story is that the explanation why KDE is the only desktop environment that is so crashy on Nvidia hardware is because Martin decided at one point that he doesn’t want to test on Nvidia hardware.
            Now, the rest of the community has to suffer because of 1 decision and that in turn drives users away to Gnome.

            I have the impression that since the Mir debacle, the community spirit in KWin changed a bit…

            1. I’m not hindering anyone to fix nvidia specific issues. I absolutely don’t get what the heck this is about.

              1. Oh, well, certain people simply want you to do more unpaid work for them.

                Anyway, I appreciate KWin very much, it’s really fun to work with!

          5. Thank you for the clarification and all your hard work.
            You stating that you CAN’T reproduce bugs is a bit confusing though. Given that Nvidia offers you free hardware it is more like that you WON’T.
            It is absolutely your prerogative to refuse whatever for whatever reason, I just wish that the reasons were more clear. They are now.

            1. Do you think I’m able to reproduce each bug? In most cases it’s still a can’t reproduce. If it were as simple as adding an NVIDIA card to reproduce issues, don’t you think someone would have done so? KDE can afford those 50 bugs.

        2. “we’re eager to hear about that and fix it, but we need a real bug report for that, that exposes the problem.”

          Sounds like NVidia is too cheap to do QA themselves. Lending out hardware and expecting that others do the actual work for free only shows how little NVidia values paying customers.

          Maybe consider an alternative when your next hardware purchase is imminent.

          1. Unfortunately there is no real alternative hardware. Nvidia is so much more power efficient than amd hardware. I simply don’t want amd for that reason! (70W vs 300W)

            I think nvidia doesn’t care much of a 1-2% linux market share so I fear this will be a never ending story.

      2. > I cannot reproduce the problem and the backtraces are incomplete and missing debug symbols

        I guess a bunch of these come from archlinux users, which IMHO are quite familiar with crashing applications & reporting their bugs (note I’m biased here as an archlinux user myself). However they’re humbled by archlinux not providing debug symbol packages, because the distribution build system isn’t able to separate these into an extra repository (and they don’t want to put it into the main repos, because it’s so big). Dunno if KDE people are aware of that situation, maybe somebody is at the right place to improve for both sides here, and just needs to know?

        ref: https://bugs.archlinux.org/task/38755
        https://bugs.archlinux.org/task/10975
        https://bugs.archlinux.org/task/20921

        1. Unfortunately I’m aware and very annoyed by the time wasted because of Arch allowing to submit such reports. Not my time, the user’s time.

        1. The KDE community is larger than me. Just because I don’t care about NVIDIA specific issues, doesn’t mean nobody else can tackle them. Including all those people having NVIDIA cards. Our code is open, feel free to hack on it!

  7. A bit off topic I guess, but while I do check from time to time and it really keeps getting better and better, I’m abstaining from switching to Wayland due to its proper hidpi support… yes, support, not lack of it 😛

    I surely won’t switch full time at least until I’m able to run Firefox at proper resolution. Under X11, I’ve configured basically everything I use to work well with hidpi display. When I try KWin/Wayland, Plasma and other KDE stuff works well, but anything that still uses X is then doubly scaled up, so I need to disable hidpi handling in X apps, which in turn results in ugly pixelated mess instead of a sharp-looking browser on my screen.

    The best solution I dream of would be an ability to set up a KWin rule to force enable/disable scaling (and maybe a wayy to change the DPI setting for XWayland). I would then keep it disabled for all X11 apps except of few exceptions. Also, a window menu option to toggle it could be handy. Is it something that can be reasonably expected to come to KWin?

    (also, would it be possible to scale using some filtering to avoid pixeloze? hidpi scaling doesn’t seem to respect the quality setting in compositor kcm tab at all)

    1. The window specific rule to disable scaling is a good idea. It’s nothing I had thought of yet. I think that should be doable and I hope to remember once the general rule setup is finished (almost there).

  8. In general, I am all for moving on to Wayland. And the feature freeze makes a lot of since.

    I only wish you make one exception to the feature freeze. There are several groups working on HDR support for both Wayland and X11. When that work finalizes, I would like for Kwin to support HDR accross both stacks. Mainly thanks to the major commercial 3D DCCs such as Maya are still X11 only, and are slow to adopt new Display tech not on Windows.

  9. Everything in this post looks sensible to me! What I don’t like, however, is how much software (Firefox, Thunderbird, etc.) important to my daily life doesn’t run natively in wayland.

  11. Martin, thanks for all your hard work on KDE. I’m sure everyone is asking about their pet missing feature – in my case that’s the xmodmap support. Am I correct in assuming that this role will be taken over by kwin as well?

    1. I haven’t fully understood how xmodmap can be used on Wayland. It is in our showstopper list.

  13. I’ve been using NVidia hardware for years, because I also need it games and work, because it’s widespread, because it’s powerful. Most of the people I know owns nvidia graphic cards.

    So what is the future for us ? No KDE ?
    Refusing free hardware to test it works for many thousands of KDE users ? What the hell ?

    I think with time someone will fix this once KDE gets so many bug reports about not being able to run KDE.

      1. Yes indeed. And I should have started by saying thank you!
        I just hope home nvidia users won’t be left behind with time and wayland usage increasing.

  14. It’s good that way. At some point you’ll have to start to phase out X11 development, and coupling it with a LTS release makes sense

    It’s just about new features, as long as it’s still in maintenance on a bugfix level all is fine.

    It’s good too, because it probably (likely?) will free up resources for improving KWin on Wayland.

  15. I just gave Plasma/Wayland a try, but switch immediatley back to X11. There is no virtual Desktop support (yet) which I depend heavily on in my daily workflow. I usually spread my running windows/tools across the 12 virtual desktops (Meta+F1-12) for better task focussing.

      1. Okay, I’m open for suggestions: So how do I map meta+F1..F12 keys to their virtual desktops without pager knowing about this virtual desktops? Even running plasma/wayland this one time discarded my already configured keyboard mappings.

  16. Goodbye KDE. You partially made me use windows 10 again. And others will be happy on Gnome. A handful of those who stay, good luck to you.

          1. No new X11 features for KDE. No EGLstreams support. I dont use X11 at all anymore. I just manage a few gentoo servers now. And i wont return to the linux desktop until they get rid of GBM, the mentality in the linux/gnu sphere and make wayland actually usable/productive. That just my choice and many others will as well i am sure.

  17. Thank you for all your hard work and for the detailed explanations in this post. Concentrating now on Wayland feels right, I’m happy that this is announced for Kwin now. I use Wayland already every day and the things that aren’t ready yet, wouldn’t get better without decisions like this. Personally I cannot understand post from Nvidia customers here, one kwin developer is definitively not the right person to fix all the bugs of a multi billion dollar company with thousands of developers. If your are not happy with your purchase, return it to Nvidia or get it contact with them to fix their bugs in their closed drivers. As a AMD customer, I did the same for the Ryzen segfaults or missing audio via HDMI and they did respond. Complaining is fine as long as we complain at the right place, personally I would waste my time with doing this over and over at the wrong place.

    1. I fully agree. Since many years I’m using only Intel and AMD graphics hardware. Nvidia disqualified itself by many decisions it did, especially by not supporting or even blocking development of open source drivers. If more users would have acted like me Nvidia would perhaps have changed it’s mind faster.

      Thank you, Martin, for all the hard work! I’m looking forward to using Wayland in the near future.

  18. People who use a free operating system are fully entitled to buy proprietary hardware and try to use it with proprietary drivers.

    However, once they do that they are on their own. When you use a proprietary driver you lose the right to even *expect* it to work – at all – with free software. You most obviously are *not* entitled to whine about it.

    Sheesh.

  19. Pingback: Keine neuen X11-Features für Kwin

  20. Thanks for this very helpful and informative post.

    However, Wayland still doesn’t exist for me since too many things don’t work correctly and there is still Nvidia issue. There was a vast improvement in Wayland area because a few months ago it either didn’t start or started with so massive bugs that hard reboot was necessary. Lately, most things worked correctly so it was “WOW” effect for me. With longer testing, there were still issues and Wayland is still not usable in the long run for average user.

    I’m not a tech user so I don’t even know where to start with submitting bugs with Wayland so for me it’s like: I stay away from Wayland as long it’s possible and many others feel and act the same. This means that the community feedback is still just a fraction of what it could be. Wayland may be the future but the present is still with X, alas.

    I agree with the reasoning behind those decisions and I support them except the last statement:

    “KWin won’t be adjusted to any new requirements in the XServer, Mesa, input stack, proprietary drivers, etc. If something breaks it’s the fault of those components which broke it.”

    That’s UNREALISTIC and UNFAIR to users. Be honest, Kwin is a little fish compared to some other projects and brutal reality is, small fish must adjust to bigger one, at least in most cases. If not, users will suffer in the process. There will be new features and releases of those packages and they might break something. It is not a matter of IF but a matter of WHEN. For this Kwin has to make an exception and simply adjust to the newer packages, otherwise, MAJORITY OF KWIN USERS will be hurt seriously. Because KwinX stops developing new features, it doesn’t mean X related projects stop as well. If those projects can fix things they broke with Kwin, it’s great but some just won’t care….

    So LTS can’t mean it will ignore essential X related changes.

    As a user, I hate the game of pulling the rope of “that’s not my fault”. We don’t really care who’s fault it was! If I was a developer and new Plasma added something that broke functionality in my program, I would have to update my program, not blame Plasma and expect it to fix what they did to my program… Such things already happened with for example SMplayer, where something broke global menu in the program after an update, SMplayer had to fix it. Plasma, Kwin or Qt wouldn’t bother fixing this. Again, little fish has to adjust to the bigger one, at least in boundaries of reason.

    1. You’ve failed to understand Micheal’s point. Any time they add a new feature it means the interactions with x cause unexpected consequences.

      Reworking the kwin to work against a changed API, will cause exactly the same kind of bugs.

      Reading his post it sounds like they’ve automated most of the wayland/libinput stack. This means changes can be made quickly and they can be confident they haven’t broken anything.

      Changing x11 features, means manual testing. That is deeply time consuming and without detailed documented tests it will give highly variable results. So a small x11 change consumes a lot of developer time.

      X11 devs became Wayland devs so large breaking changes are unlikely. I suspect it will be a security flaw that requires a breaking change. I’m guessing Martian would rather focus on getting wayland in a great position than spends months keeping legacy x11 going.

      If you read his argument I suspect if someone figured out how to automate testing against x11 he would keep it going. Alas I think x11s design prevents this.

        1. Nvidia is a special case… I understand that there is simply no manpower in KDE/Kwin teams to maintain two standards. But for all other things, some flexibility and reason is needed. We may not have any new X features and that’s fine, but when X related packages introduce something new that has to be implemented in Kwin otherwise it will be broken, Kwin has to adjust to it. We are not in phase of X only maintaining mode worldwide yet.

          1. but when X related packages introduce something new that has to be implemented in Kwin otherwise it will be broken, Kwin has to adjust to it

            No, absolutely no. If existing software gets broken, the change is not allowed to go in. That’s pretty much a baseline for the development in the Linux kernel: never break user space. It is not asked much from the X community to do exactly that. And btw. this works. I practiced this a few times already to tell upstream a clear: no, we won’t adjust our code. And that worked. Upstream adjusted to not break.

                1. Yeah i get that. On a server linux rarely breaks userspace if ever but on a desktop it breaks regurarely. Not because of bugs. Because of changes. Sure this breakage is rarely found within the GNU toolchain, libs and programs. But in other software it happens.

                  1. I am not sure you got that 😉

                    The userspace is everything outside of kernel space. If there is breakage, it is between applications and libraries in the userspace, not kernel space, but that’s an entierely different problem. The point is: you can boot an old linux distribution from the 90’s with a very recent kernel (at least in theory). That’s forward compatibility!

                    1. Suuure. All the patches i had to apply to get things between userspace and kernelspace working were just imaginary then.

  21. Many very confused (hurt?) readers here, expecting human software & hardware to be absolutely PERFECT. The commercial, highly privatized brands (Microsoft, Apple, etc) will give the illusion for the gullible: they are and will always be “perfect”. Such are the joys of childhood innocence.

    Linux has many reasons for leaving the “prison of leaning X.org. for Wayland, or other display drivers of many kinds. These software item have the usual major problems. Bugs, feature missing, & poor optimizations, etc. Particularly in the early releases of the code.

    Then each software release has the lack of alpha & beta testers, with their unusual, unpredictable setups & needs. Whatever “choices” made, will always be a compromise between speed, accuracy, fidelity, and adjustments.

    On my old hardware, will the GPU’s handle the screen displays, easily & smoothly enough, for the moment? Are better GPU’s needed? Many (most?) modern computers can run two or more screen displays, simultaneously. Often USB3, wireless-transmitters, or other plugins may be needed. When we use these external monitors, can the different DPI rates be handled at all, or simultaneously?

    In the weeks ahead, all operating systems, including Linux, will be facing these challenges. Luckily the religious here can believe n the infallibility of the god-like brand-names.

    The rest of us Linux mortals must meanwhile make-do with human creations. Hardware architectures and firmware coming from AMD, Intel, Nvidia. Then always-imperfect software from the hardware makers, plus the others from third parties, like Nouveau, bumblebee, Wayland & X.org, etc. It is so hard being human. Where are the god(s), when I need them, now? Tooth-fairy is not working, as it used to work.

  23. Pingback: Late Night Linux – Episode 29 – Late Night Linux

  24. I have to use kubuntu because that the only distro which just works in my usecase. How do I test kde + wayland?
    I’m happy to test and to report bug but where is the doc explaining step by step how I can setup a configuration which is worth tests?

    1. I’m sorry, but I don’t know for every distribution how to set it up. You have to ask your distributor.

  25. I’m not sure it is the distro business. I will try to open a feature request on kubuntu (maybe it already exist) but I don’t think it should be distro dependent. The end result depends on the version of kwin but the way to set it up shouldn’t. If it does depends on the way the packets have been compiled or a dependences which are not honored by the distro, then it simply means that it is still too early to ask even experienced users to test kwin with wayland. The breakthrough will occur when these experienced users will have a reasonable way to play with wayland. I expected to find at least a generic short doc showing how to set that up. If it does not work then I have something concrete to report to the distro. Could be that this doc exists but I was not able to find it.
    So what’s the “generic way” of starting kwin with wayland instead of X? Any pointer to a doc is appreciated.

    1. The generic way is “Select session Plasma Wayland in SDDM”. But how to get Plasma Wayland is up to the distribution. It might be automatically installed, it might be an additional package, maybe an additional repository. That’s something I do not know and don’t want to know.

      1. OK so at least I know that I have to check what’s going on with SDDM. There is nothing else to configure manually, no environmental variable or who knows what.
        I understand you don’t want to know and I hope it will be, if not selected by default, at least available by default soon in the distributions…otherwise the audience will remain very limited.

        1. Well, on kubuntu 17.10 it is as simple as sudo apt install plasma-workspace-wayland ans then one can select wayland in SSDM. Cool. It is sad that almost nobody advertises for it because I haven’t found a missing feature (for my basic usage). It is more than bearly “usable” and people should give it a try (intel drivers).

Comments are closed.