Re: F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 8, 2020 at 11:56 AM Erich Eickmeyer
<eeickmeyer@xxxxxxxxxxxxxxxxx> 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: ngompa13@xxxxxxxxx, rdieter@xxxxxxxxx, jgrulich@xxxxxxxxxx
> > * 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux