Bug 1882465

I don't want to block this on bug 1912046, since that can cause major problems regardless of X11 or Wayland session.

(In reply to Neal Gompa from comment #1)
> I don't want to block this on bug 1912046, since that can cause major
> problems regardless of X11 or Wayland session.

Neal, there is a difference between "can cause" and "will cause".  
It is now documented that if you use SDDM to start plasma-wayland
and you have the program environment-modules installed, you'll get
a black screen.  The initialization sequence is different with X11
and this issue does not occur.

I believe plasma-wayland is a great idea, and have been doing quite
a bit of testing with it, creating upstream bugs, etc.

This is the only issue I've found so far that I would consider 
seriously problematic.  The good thing is now it has been identified
and documented.  The only problem now is getting all the upstream
developers of the upstream components on the same page.  
What is your proposed mitigation if this isn't fixed?

Reminder: The change complete (100% complete) deadline for Fedora 34 changes is Tuesday 23 February. At that point, changes should be 100% code complete, along with supporting documentation where appropriate. Please indicate this by setting the tracker bug for your change to ON_QA.

Bug 1877521 is a regression from X11, so adding it as dependency.

These upstream KDE bugs also affect F34 and constitute regressions from the Plasma X11 session:

1. https://bugs.kde.org/show_bug.cgi?id=422426 - middle-click paste not working between KDE and GTK apps
2. https://bugs.kde.org/show_bug.cgi?id=424754 - copy-paste sometimes not working in GTK apps
3. https://bugs.kde.org/show_bug.cgi?id=430862 - kinit5 crashes when clicking Copy on a screenshot notification
4. https://bugs.kde.org/show_bug.cgi?id=429967 - Gwenview and other apps on Wayland have "transparent" areas (i.e. not being painted)

In just a few days of testing Wayland, I have encountered several other regressions. I'm slowly reporting them upstream.

Another one:

5. https://bugs.kde.org/show_bug.cgi?id=434968 - Snap-to-border halo effect remains visible after dropping a window close to a screen border

(In reply to Bernie Innocenti from comment #6)
> 5. https://bugs.kde.org/show_bug.cgi?id=434968 - Snap-to-border halo effect remains visible after dropping a window close to a screen border

This one is also present on X11. Perhaps it's a 5.21.x regression, but not Wayland specific.

Ideally, if you want us to track individual items, those each should be a separate bug, and then can be referenced here (as blocker, depend on, whatever).

This bug should not be used as a dumping ground.

I will try to follow that advice for the middle-click/copy-paste related issues as time allows.  Any/all assistance to do so for all/remaining issues is very welcome and encouraged.  Thanks!

Is this still an accepted change for Fedora 34? There are numerous blocking issues that make this seem not ready for release yet.

Found this ticket after update existing F33 -> F34. Wayland was enabled after it (I use KDE).

- Max display resolution became limited to 1024*768. Native is 1920*1200. Seems like problems with EDID read, monitor name contained "TODO". Similar: bug #1755468, bug #1813222.
- Several KDE apps crashed at startup while trying to autorestore previous session.
- At some moment keyboard input broke like ctrl key was constantly pressed (it was not).
- Mouse copy-paste stopped to work. Maybe the issues already referenced here.

Does not seem ready to launch. Returned previous X configuration.
Unexpectedly https://fedoraproject.org/wiki/Common_F34_bugs page is silent regarding Wayland issues.

> Ideally, if you want us to track individual items, those each should be a separate bug, and then can be referenced here (as blocker, depend on, whatever).

Sorry for adding blockers so late in the release cycle. I just didn't notice Rex's comment until yesterday.

I just linked Bug #1949821. In case it affects all users with Intel GPUs, I think it should be considered a blocker for the Plasma Wayland by default feature.

I also think Bug #1877230 should be a hard blocker because it breaks basic clipboard usage between KDE apps and browsers. We already have a fix upstream, so it's just a matter of getting it in the Fedora gtk3 package.

Downgrading Bug #1949821 to non-blocker because it's a minor Wayland regression not present in the default configuration of Gwenview.

SimpleScreenRecorder does not work with Wayland: https://github.com/MaartenBaert/ssr/issues/431

vokoscreenNG does not work with Wayland: https://github.com/vkohaupt/vokoscreenNG/issues/51

Qt issue exists that can cause stability issues: https://bugreports.qt.io/browse/QTBUG-81504

Jitsi meet has issues with screen sharing on Wayland: https://github.com/jitsi/jitsi-meet/issues/7437

Screen sharing does not work with Zoom on Wayland: https://github.com/flathub/us.zoom.Zoom/issues/22


I don't believe the default for Fedora KDE should be one that introduces many issues, especially stability issues for the average user. I usually leave my systems running for months on end, I have experimented with Wayland on Fedora 33 and 34 beta with KDE and sessions constantly crash, barely last a day, this should not be the default for Fedora. Especially these days are people are dependent on their computers working more than ever. Why should someone's Zoom suddenly stop being able to screenshare? 

Wayland is not ready as a 1:1 compatible Xorg replacement just yet, even with XWayland there are problems.

To add, xdotool also does not work: https://github.com/jordansissel/xdotool/issues/282

With no possible replacement that is worthy of replacing it yet.

There's also issues with color management: https://discuss.pixls.us/t/wayland-color-management/10804/519

While progress is being made, it is still not ready: https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/

Not a blocker, but Bug #1952594 is also quite irritating (gpg password prompts appear minimized in Plasma Wayland).

To all other comments claiming that Wayland isn't ready: while I agree with the sentiment of not introducing known regressions, GNOME has already been using Wayland by default for several Fedora releases now. It wouldn't be fair to hold KDE to a higher quality standard.

Some of the software that currently doesn't work in Wayland probably never will, and KDE can't do anything about it. For instance, screen captures is a privileged operation in Wayland's security design, and  SimpleScreenRecorder doesn't support the necessary protocol. However, Wayland support was recently merged into OBS Studio so there's an alternative.

Screen sharing not working in Jitsi Meet is more worrisome, because it probably affects all web-based video conferencing apps. I tried toggling chrome://flags/#enable-webrtc-pipewire-capturer, and I still cannot share the entire screen (I can share individual windows though). This might be a bug in xdg-desktop-portal-kde, needs more investigation.

(In reply to Bernie Innocenti from comment #16)
> To all other comments claiming that Wayland isn't ready: while I agree with
> the sentiment of not introducing known regressions, GNOME has already been
> using Wayland by default for several Fedora releases now. It wouldn't be
> fair to hold KDE to a higher quality standard.

In all honesty, GNOME under Wayland is a very stable and usable experience, however KDE is a completely different story. I agree that once KDE is as good as GNOME was when it made the switch, that the switch should happen. However that is not the case at this time. 

At the very least, all the Wayland showstoppers should be fixed before pushing Wayland as the default for KDE: https://community.kde.org/Plasma/Wayland_Showstoppers


What reason is there to introduce numerous known issues to the default config of KDE? All this will accomplish is sour the opinion users have of Fedora and KDE.

(In reply to danielsuarez369 from comment #17)
> At the very least, all the Wayland showstoppers should be fixed before
> pushing Wayland as the default for KDE:
> https://community.kde.org/Plasma/Wayland_Showstoppers

As Rex said in comment #11, ideally any regressions affecting Fedora users in a significant way should be filed individually and referenced here as blockers.

While I respect all the hard work of the people involved with the Plasma Wayland session, I believe that the two regressions already listed (#1877230 and #1877521) would be severe enough to defer the feature to F35 -- and I'm saying this while being a full-time user of Plasma Wayland on both Fedora and Arch Linux.

Closing Changes Tracking bugs for the Fedora Linux 34 release. If your change did not make it into the release, please reopen and needinfo bcotton.

I agree.