Going all-in on a Wayland future

Community
, ,
1

We all knew this will happen eventually, but I honestly think it’s still too soon. I mean, it’s 2027, not now, but it’s hard for me to believe everything will be ironed out before then. I mean, yes, the article does give the suggestion of LTS distros, Debian and Kubuntu will ship some kind of supported Plasma setup with X11 well into the 2030s… I am still not convinced though.

What about NVIDIA GPUs?
While Wayland support in the proprietary NVIDIA driver was quite rocky a few years ago, it has matured tremendously. Graphics cards still supported by the manufacturer work just fine nowadays, and for very old NVIDIA GPUs, the open source Nouveau driver can be used instead.

There are still very much usable Nvidia GPUs that are old enough not to have an up-to-date official driver, but new enough not to work (well) with Nouveau. This is the case with my former GPU, the GTX 660. I still own it, but no longer use it, mostly due to exactly the rocky Linux support, but it was fiiiiine on X11 with the official driver. I am lucky enough to have been able to afford an RX 580, which is a mostly great experience on Linux (with Plasma on Wayland), but many people are stuck with the hardware they have.

Last time (few months back) I tried running Plasma Wayland on that GPU with Nouveau, I got constant crashes in Mesa code for anything that uses OpenGL (yes, that includes plasmashell and kwin, it was frankly unusable). I imagine if I was even able to launch a game, it wouldn’t run as well as on the proprietary driver either (yes, this GPU can game, obviously limited to indies and older big titles, but it can). Maybe this improves before 2027 (maybe it already improved in those few months…?), but yeah, I think the Nvidia hardware issue is a real one.

3 Likes
2

I too am leery at the countdown commencing, with my own deal-breaker factor (headless remote desktop) still very much up in the air.

Since 6.5.x I decided to start daily-driving the Wayland session at home, and it’s … mostly OK, I won’t rehash any of the papercuts we all know quite well but nothing I can’t live with for the sake of staying KDE.

Unfortunately ~50% of my computer time (the working part) is spent on a remote desktop, and for that desktop to keep being KDE, that limitation needs to be overcome. If a reliable solution emerges in the time left, my money is on it coming from outside KDE: xrdp is putting a lot of attention to it currently, and Sunshine although being geared more to gaming than productivity, usefully lacks other projects’ reticence about attacking the solution at a lower level that makes X vs Wayland irrelevant. vkms in the kernel is also progressing where, paired with Sunshine or something else, it may get us there.

So the clock is ticking. I won’t sweat it yet, but I do fear bitrot and likely dev disinterest in resolving novel X11-session bugs from this point onwards, which could hasten the end at any time. In my case, I don’t want the schizophrenia of one desktop at work and another at home, so I will be grooming KDE’s potential replacement.

2 Likes
3

For me it’s the Bumblebee hybrid grafic topic which prevents me from switching to Wayland. I need this to run my two monitor setup.

4

I am using Wayland. The reason for that is, X11 is worse. It crashes my work-application within a minute after start-up finished. If that wouldn’t be the case, I would still stick with X11, because the same application that works perfectly on X11 is super bugged on Wayland with broken multi-window placement and sizing and scaling. That only happens in combination of 3 monitors (2 monitors are fine). So I can decide between not functional or a mess, so I decided for the mess.

Since that is the case, I am not affected by the end of X11, but it also shows where others could be affected. For those I hope Wayland has no major issue any longer at 6.8. Otherwise KDE may should consider to delay dropping X11. Personally I hope my issue above is solved with Debian 14, so that I do not need to deal with it another two years on top. I know developers are doing their best and also have other issues to fix, but I have to deal with this bug all the time.

5

Remote desktop does work in 6.5 with wayland. You only need to allow the app (e.g. Rustdesk) without asking (System-Settings → permissions → apps → RustDesk, if I remember correctly). It should work with other apps too.

2 Likes
6

multigpus with wayland is much better and works out of the box.
bumblebee is also long replaced by prime render offload /nvidia prime

1 Like
7

That’s not headless though. The problem at present is there is no way of launching a plasma-wayland session with solely virtual display (well, there are other problems but that is numero uno).

2 Likes
8

I wrote about my remote desktop use case (x11vnc) on the reddit thread for this topic. RDP and Sunshine(lol!) are not acceptable options to replace it, they are not the VNC protocol and do not share the same features.

Futher, window positioning in a hybrid floating/tiled setup is incredibly important. Wayland users don’t seem to care when multi-window applications spawn a messy stack in the middle of the primary display. In X11, all application windows behave predictably because individual windows can be identified and handled, but Wayland by design cannot identify windows in that manner. Please do correct me if I’m wrong, but this is an intrinsic limitation in Wayland that requires the forbidden ext-zones protocol to address.

Each time I give Wayland a fair chance, these factors drive me back to X11. Window positioning is a dead stall for me, I value this beyond many other features.

2 Likes
9

In X11 it is mostly the application’s responsibility to place windows, for initial placement and restoring a previous arrangement.

Which is why the commonly fail for anything than the most common window manager behavior.
E.g. I have yet to find a single application which correctly restores on the activity it was previously stored on.

On Wayland, the restore part is shared responsibility between application and window manager.

Essentially the application says “I’d like you to restore this window” and the window manager can apply the data it has stored for that window. On Plasma that means that KWin can restore Activity association as easily as virtual desktop or screen.

Hopefully this receives enough testing so we will get this finalized and enabled by default soon.

This is still under development/discussion and will help with the initial placement part of the problem. The proposal had run through several iterations and arrived at a pretty good state, with draft implementations being available for both sides.

Unfortunately someone felt the need to derail this effort by drawing the attention of uninvolved parties toward the discussion, basically drowning discussion between stakeholders, forcing a temporary hold.

Personally I was sad that some people felt they need to sabotage collaboration between app and desktop developers that way.

Ultimately this will either move communication to private channels, result in major delays for solutions or burn enough contributors in the current generation to defer progress to the next one.

4 Likes
10

I appreciate the details, but I disagree “that” YouTube video soured the proposal, it directed necessary attention to the issue.

The protocol absolutely needs a fire lit under it, and compromises will need to be made if it’s to be implemented by the time kwin-x11 is archived. If that’s accomplished by prospective users of the feature gatecrashing the MR, then the aforementiomed stakeholders need to take note.

I realize this is a harsh take, but it’s incredible to see the amount of “this isn’t good enough, we can do better” in the Wayland Gitlab, while nothing moves except drafts. X11 cannot be put into the ground until it’s figured out.

You’ve had this issue in X11? Activities may be different, but I can close a Firefox session with ~10 windows spread across 4 virtual desktops, when I re-open all windows are placed on the virtual desktop and quick-tile I left them in. Wayland dumps them all on the primary display.

Sorry, I misunderstood. Activities being a KDE-specific feature, I wouldn’t expect any dev of a non-KDE app to cater to it. It would make sense that it’s the window manager/compositor’s job to keep track of activities, but that’s not the case?

11

The problem is that a social media posting is the worst possible way to do that.

This might get the attention of a handful of developers who were unaware of the effort but at the same time it creates an enormous amount of noise.

The result is often, like in this case, that any actual discussion becomes impossible, in the best case pausing, in the worst case halting progress on the issue at hand.

It is unclear whether the motivation to do that was to sabotage the proposal or just someone not considering that this would be the likely outcome.

Anyone who would have wanted to increase awareness would have contacted people who could have contributed to the protocol in a meaningful manner, e.g. developers of toolkits and applications in need of the feature set.

How would that ever be the result?

Making it impossible for stakeholder to communicate result in the very opposite.
The MR in question is now a no-go zone for developers and will be stalled for several months.

This is how protocols and standards are established.
An iterative approach that tries to minimize ambiguity in phrasing, overlap and potential conflict with already established ones, and so on.

The alternative is to burden client and server side with supporting several versions of the same protocol, lots of hidden bugs due to interpretation misunderstanding, and general unhappiness for both developers and users.

Unfortunately a lot of people are motivated to drag this out as long as possible.
If necessary by harming progress on Wayland.

I would expect windows to show up where they were when their position were saved.
That includes which activities they were on.

I agree that this is not necessarily something the app can do or even want to do.
Hence the improved approach in Wayland which makes window state and positioning the responsibility of the component that actually knows all of this: the window manager.

On X11 there is no way for the window manager to distinguish between a new window and a restored window.

On Wayland, the respective protocol enables exactly that.

2 Likes
12

I highly doubt sabotage. If we’re referencing the same video, the purpose was to bring attention to one of the last remaining X11 abilities that Wayland lacks.

I see it as end users wanting a good-enough solution soon enough, not a perfect solution that will never be agreed upon with full consensus.

That’s a decision made for what reason, to punish proponents for drawing attention to an outstanding feature? I understand there were wholly unconstructive flame comments, but I can’t imagine the entire effort is just paused for those.

If developers are driven to hidden channels to discuss protocols that affect all users of an open source project, that indicates a problem elsewhere.

My workflows aren’t just going to go away, and Wayland does not support them yet. Don’t get me wrong, I want Wayland to be better and indistinguishable from X11 in any use case. Until then, I’ll just have to shop for an LTS distro.

1 Like
13

Not sure about Wayland but in X11 it works terribly there for me for some reason: most windows opened in their previous saved positions, but new windows (for example file or auth dialogs) it tries to open/create in top-left corner while settings said they should be created/shown in the screen center.

14

Recently tried Wayland: works much better than before - did not break my X11 saved/restored session any more - restored all the windows correctly. Only konsole opened 1 terminal tab for me instead of 3. Looks and works mostly fine for me, for example, I like system scaling for old apps, HDR, color profiles, etc.

Just small lacks:

  • Not all apps restored correctly like I mentioned above with konsole.

  • HiDPI global scaling ratio scales/calculates apps and fonts sizes differently in X11 and Wayland for some reason, so need to correct its value after switching.

  • Gkrellm is not accepted as a panel in Wayland or XWayland and produces entry in task bar.

15

This used to happen in X11, dialogs would open near 0,0 in X11 coords (the top-left of my left secondary screen, so a very incorrect place), and it was more common with pop-ups like auth/polkit and confirmations. Even KDE components had this issue.

It seemed to have been fixed during Plasma 5’s lifecycle, I don’t know if it was a code change or application developers fixing things over time. Can’t replicate it now: new dialogs open under my cursor, the default centered position works as well. Does the same thing happen in a fresh user profile?

16

Yes, opened in the center few times, then started to open in top left again.

1 Like
17

Very interesting, I’ve tried in a fresh profile, the polkit dialog from pkexec spawns properly in the center each time, over dozens of tries. Are you on the latest Plasma desktop (6.5.3 at the moment)?

Previously, it definitely had issues: I often elevate my lower-privileged work account so I saw it often, and could swear it was fixed well over a year ago.

18

Yes, the latest.

Seems not!

19

We can obviously only speculate about the motivations.

It could have just been a naive attempt at generating views for their channel without considering the collateral damage it could cause.

They might even have honestly believed that flooding the channel would have a positive outcome.

Sadly anyone who has participated in collaborative work could have told them that a low noise environment is more conductive than the equivalent of random people talking over each other.

it might not be paused in the sense of a conscious decision to halt work for a while but the resulting need to find alternative means of communication have the same effect.

Yes, unfortunately there are people who don’t understand how collaborative development works and how damaging it can be to create distraction and noise.

In the best case it leads to a move to hidden/private channels, in the worst case to a collapse of work.

In either case those would be in most need for the work to be completed are the ones most harmed by the detractors.

For now we can only hope that the work continues regardless, was not totally derailed and did not deter others from starting similar efforts.

3 Likes
20

We’d see fewer “Wayland still doesn’t have <basic/universal function>“ videos if certain individuals I needn’t name didn’t respond to proposals for such with some version of “No“ in a tone that conveys “how dare you want this“. Be it because Windows does it or because Mac does it or because X11 does it (all of which unbelievably stupid reasons for “the future“ of an OS family running on less than 10% of desktops), in my view those people and that attitude do far more harm to Wayland (and Linux as a whole) than any youtube video shining a light on them.

2 Likes