On Tue, Sep 8, 2020 at 11:56 AM Erich Eickmeyer <eeickme...@fedoraproject.org> wrote: > > Hi Ben, > > On 9/8/2020 8:28 AM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma > > > > == Summary == > > Change the default session selection in SDDM to prefer the > > Wayland-based KDE Plasma Desktop session over the X11-based one. > > > > == Owner == > > * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]], > > [[User:Jgrulich|Jan Grulich]] > > * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com > > * Product: KDE Spin > > * Responsible WG: KDE SIG > > > > > > == Detailed Description == > > > > With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a > > point where nearly all commonly used features in the desktop and all > > major applications function in the Plasma Wayland environment on all > > major GPUs (including NVIDIA with the proprietary driver). Starting > > with Plasma 5.20 in Fedora 34, we will change the default > > configuration for Wayland and X11 Plasma sessions so that Wayland is > > preferred and used by default, while permitting the X11 session to be > > selected as the alternative desktop environment option. > > > > == Feedback == > > > > ==== Is Wayland ready? ==== > > Wayland has been used by default for Fedora Workstation (which uses > > GNOME) since Fedora 25. And while it was somewhat immature initially, > > today it is a very rock-solid experience on virtually everything > > Fedora Workstation runs on. The change in Fedora 25 kickstarted the > > drive to get everything working on Wayland, and the Workstation team > > succeeded beyond their wildest dreams. Firefox has been Wayland-native > > by default since Fedora 31 as well. > > > > On the KDE side, serious work into supporting Wayland started shortly > > after GNOME switched to Wayland by default. Unlike GNOME, KDE has a > > much broader stack in its toolkit, and it has taken longer to get to a > > usable state. With the Plasma 5.20 release, the Wayland protocol for > > screencasting as well as middle-click paste finally are supported, > > completing the required feature set for switching to Wayland by > > default. > > > > ==== What about NVIDIA? ==== > > Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary > > driver on Wayland. It needs to be manually activated, which will be > > taken care of by the <code>kwin-wayland-nvidia</code> package. So the > > expectation is that all major GPUs will work just fine. > > > > ==== Why not keep using X11? ==== > > The fact of the matter is, Xorg is in > > [https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/ > > "hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and > > development on it has basically stopped beyond the most critical of > > fixes. Combined with the rapid maturation of the Wayland session in > > KDE Plasma, this is the best time to make the switch and push things > > over the edge for the KDE ecosystem in the same way that Fedora > > Workstation did for the GNOME ecosystem. > > > > == Benefit to Fedora == > > Fedora has long been a leader in advancing the adoption of the Wayland > > protocol as part of the overall strategy to improve the Linux > > graphical software stack. Much of the quality of Wayland for GNOME can > > be attributed to the work done by the Fedora Workstation WG as part of > > advancing the GNOME platform. It is now the KDE SIG's turn to do the > > same for the KDE platform. By making this change, we are helping push > > the adoption forward for newer, more streamlined, and overall more > > actively developed graphics technology for the KDE ecosystem. > > > > == Scope == > > * Proposal owners: > > ** Modify {{package|kwin}} to switch to Wayland > > *** Split out <code>/usr/bin/kwin_x11</code> to the > > <code>kwin-x11</code> subpackage. > > *** Make {{package|kwin}} require <code>kwin-wayland</code> and > > recommend <code>kwin-x11</code> > > *** Add <code>kwin-wayland-nvidia</code> subpackage which contains > > <code>/usr/lib/environment.d/10-kwin-wayland-nvidia.conf</code> to set > > <code>$KWIN_DRM_USE_EGL_STREAMS</code> to <code>1</code>. This package > > will have have a Supplements dependency <code>(kwin-wayland and > > kmod-nvidia)</code>. > > ** Modify {{package|plasma-workspace}} to switch to Wayland > > *** Rename <code>/usr/share/xsessions/plasma.desktop</code> to > > <code>/usr/share/xsessions/plasma-xorg.desktop</code>, subpackage it > > out as <code>plasma-workspace-xorg</code>, and have it require > > <code>kwin-x11</code> > > *** Rename <code>/usr/share/wayland-sessions/plasmawayland.desktop</code> > > to <code>/usr/share/wayland-sessions/plasma.desktop</code> > > *** Make {{package|plasma-workspace}} require > > <code>plasma-workspace-wayland</code> and recommend > > <code>plasma-workspace-xorg</code> > > ** Modify <code>@kde-desktop</code> comps group for Fedora 34 to > > include <code>plasma-workspace-xorg</code> for the media. > > > > * Other developers: N/A (not applicable for this Change) > > * Release engineering: [https://pagure.io/releng/issue/9741 #9741] > > * Policies and guidelines: N/A (not needed for this Change) > > * Trademark approval: N/A (not needed for this Change) > > * Alignment with Objectives: N/A (not applicable for this Change) > > > > == Upgrade/compatibility impact == > > Systems using certain (very old) graphics hardware or graphics drivers > > (matrox, etc.) may have problems running the Wayland session. In these > > (rare) cases, users may have to configure SDDM to use X11. > > > > == How To Test == > > Log into a KDE Plasma desktop. Do any activity you would normally do > > in your daily desktop use: launching applications, configuring > > displays, etc. Things should work the same way under Wayland as they > > used to under X. > > > > == User Experience == > > The user experience should not change noticeably. > > > > == Dependencies == > > This mainly affects the {{package|plasma-workspace}} and > > {{package|kwin}} packages, and details for the changes for those > > packages are described in the Scope section. > > > > == Contingency Plan == > > * Contingency mechanism: Revert the file renames and switch > > <code>plasma-workspace-xorg</code> to be the required package instead > > of <code>plasma-workspace-wayland</code> > > * Contingency deadline: beta freeze > > * Blocks release? Yes > > * Blocks product? KDE Spin > > > > == Documentation == > > Some upstream documents about Wayland > > * https://community.kde.org/Plasma/Wayland > > * https://community.kde.org/KWin/Wayland > > > > There is currently no coherent up to date documentation about Plasma > > Wayland. > > > > == Release Notes == > > The KDE Plasma Desktop is using the Wayland display system now. X > > applications will continue to run transparently through XWayland. > > Since Fedora Jam directly depends on the Fedora KDE Spin kickstart and > carries most of its defaults, I wish someone would've talked to me about > this before this became a full-fledged change proposal and officially > posted. For the btrfs-by-default change, Neal was gracious enough to > reach out to me and ask if I thought it would benefit Jam. As I agreed, > he put my name on the list of change owners and now btrfs is the > default. In this case, I have not been given the same amount of courtesy. > > I have done some (albiet limited) testing of Wayland, and from my tests, > aside from some potential theming issues where the theme is not > supporting Wayland (really Ubuntu Studio's default theme, but that isn't > in use here), it seems to be mostly solid. Even the High DPI scaling > does a better job on Wayland. > > I see no real issues with this, and would've otherwise agreed to this > and been one of the change owners if one had simply asked me, but right > now I'm feeling a bit of tepidness since this change directly affects > Fedora Jam and I was not asked prior to it becoming an official change > proposal. Perhaps there were reasons for that, but I don't know why that > wouldn't be considered. Perhaps the thought process was that the change > to the display compositor wouldn't affect audio, but the reality is that > anything that even potentially affects CPU/GPU usage affects lowlatency > and realtime audio performance and recording since the kernel can and > sometimes does take time away from audio to do video-related processes. > > So with that, I'm really on the fence on this one. I guess I need more > time to test. But, again, I wish somebody would've asked me first. >
This was an honest mistake. I had a note to ask you, and it slipped my mind. I *had* tested Jam before making the proposal and things had looked fine from my testing. Sorry about forgetting to talk to you first. :( -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
