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

[Ben Cotton]

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: [e-mail], [e-mail], [e-mail]
* 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-...
"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.

[Erich Eickmeyer]

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: [e-mail], [e-mail], [e-mail]
> 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-...
> "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.

--
Erich Eickmeyer
Maintainer
Fedora Jam

[Neal Gompa]

On Tue, Sep 8, 2020 at 11:56 AM Erich Eickmeyer
 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: [e-mail], [e-mail], [e-mail]
> > 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-...
> > "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. :(

[Erich Eickmeyer]

Hi all

On Tue, Sep 8, 2020 at 08:56, Erich Eickmeyer 
 wrote:
> Hi Ben,
>
> On 9/8/2020 8:28 AM, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma
> > 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: [e-mail] ,
> >
> > [e-mail] , [e-mail] 
> > 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.
>
> --
> Erich Eickmeyer
> Maintainer
> Fedora Jam

I have done some testing today using Wayland with a default Fedora Jam 
from Rawhide install, using Studio Controls to set-up my audio 
permissions, setting my CPU governor to performance, and using my 
built-in audio card as my test device on my Dell Inspiron 5576 Gaming 
Laptop which has an AMD A10 (7th gen), AMD RX540 discrete graphics, and 
16GB of RAM with a SSD. I tested X11 vs Wayland.

In both cases, Jack was set to 48000Hz sample rate with a buffer size 
of 128 and 2 periods per buffer, which would be a typical setting when 
bridged to PulseAudio as was the case here. With Jack started, I 
started Carla and did some tests with various plugins while moving 
windows around, minimizing, maximizing, and other items that would work 
the compositor. I set tearing prevention to "only when cheap" but 
neither time did I notice any tearing. Additionally, Jack did not 
detect any Xruns (buffer over/under-runs) while using either X11 or 
Wayland.

With this, I also did not notice any real issues when running Wayland 
on this hardware, and believe that with the next Plasma release (5.20) 
we might actually see Plasma and Wayland more solid than ever.

Since Wayland did not interfere with any normal professional audio 
settings or performance, I will go ahead and give this my +1, 
especially since it, combined with Pipewire, may be the only way 
forward for Linux Audio as a whole.

--
Erich Eickmeyer
Maintainer
Fedora Jam

[Robert-André Mauchin]

On Tuesday, 8 September 2020 17:28:20 CEST 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: [e-mail], [e-mail], [e-mail]
> 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.

Please no, KWin Wayland makes my system crash as soon as I connect my second 
screen, and does not support essential functions like Kwin scripting, make 
Yakuake look terrible and the whole stuff feels buggy as hell.
Every time I used it thes past years, it felt buggy and in an unfinished 
state, it was like being the tester of an alpha version.

[Silvia Sánchez]

Yes, I don't see KDE Wayland sufficiently mature to actually work as a
default.  It needs more work and testing.

On Tue, 8 Sep 2020 at 18:33, Robert-André Mauchin  wrote:
> On Tuesday, 8 September 2020 17:28:20 CEST 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: [e-mail], [e-mail], [e-mail]
> > 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.
>
> Please no, KWin Wayland makes my system crash as soon as I connect my
> second
> screen, and does not support essential functions like Kwin scripting, make
> Yakuake look terrible and the whole stuff feels buggy as hell.
> Every time I used it thes past years, it felt buggy and in an unfinished
> state, it was like being the tester of an alpha version.
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Neal Gompa]

On Tue, Sep 8, 2020 at 12:57 PM Silvia Sánchez  wrote:
> Yes, I don't see KDE Wayland sufficiently mature to actually work as a default.  It needs more work and testing.
>
> On Tue, 8 Sep 2020 at 18:33, Robert-André Mauchin  wrote:
> > Please no, KWin Wayland makes my system crash as soon as I connect my second
> > screen, and does not support essential functions like Kwin scripting, make
> > Yakuake look terrible and the whole stuff feels buggy as hell.
> > Every time I used it thes past years, it felt buggy and in an unfinished
> > state, it was like being the tester of an alpha version.

A lot of work has gone into solidifying the experience upstream, and
I'm currently running Plasma 5.18.5 on F32 (on Intel GPU system) and
Plasma 5.19.5 on F33 (on NVIDIA GPU system) and things are working
pretty well so far. The plan is to do the switch in Rawhide early and
work with KDE upstream to knock out the remaining issues to offer a
solid experience with the Plasma release we ship with Fedora 34 GA.
Based on the timelines, we're probably looking at 5.22 for F34 GA, but
I want to make the switch as part of importing the 5.20 beta next week
and give feedback ASAP.

The problem with the current situation is that if we *don't* do this,
there's no pressure to push things forward upstream and get everything
*working*. Doing this will force focus and priority to get everything
working. This strategy was employed to get GNOME Wayland in good shape
and we're in a better place now than GNOME was when the switch was
made in Fedora 25.

--
真実はいつも一つ！/ Always, there's only one truth!

[José Abílio Matos]

On Tuesday, September 8, 2020 5:32:30 PM WEST Robert-André Mauchin wrote:
> Please no, KWin Wayland makes my system crash as soon as I connect my second
> screen, and does not support essential functions like Kwin scripting, make
> Yakuake look terrible and the whole stuff feels buggy as hell.
> Every time I used it thes past years, it felt buggy and in an unfinished
> state, it was like being the tester of an alpha version.

The main issue I have with wayland on kde is the support for the second 
screen. In the previous laptop it did not detect the second screen while with 
laptop the second screen is detected and show but I can not see its content.

FWIW in both cases gnome on wayland had not these issues.

If this issues are fixed I will gladly change, there are several features that 
I like there like the support for per screen scale multiplier.

[stan]

On Tue, 8 Sep 2020 11:28:20 -0400
Ben Cotton  wrote:
> ==== 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.

Does it now have support for custom keymappings?  That is, does it have
a way to set a user keymap as the default? X has a very mature system
for setting this, so I can have my custom keymapping everywhere except
in editing the grub menu.  I've thought about buying a programmable
ergonomic keyboard so this would no longer be an issue, but my current
setup works.  Will it now work in Wayland?

Does it allow booting from multiuser?  Is there something equivalent to
startx so I can start it on the virtual console of my choice?

Or are these obsolete concepts in Wayland?

[Matthew Miller]

On Tue, Sep 08, 2020 at 01:35:11PM -0700, stan via devel wrote:
> Does it now have support for custom keymappings?  That is, does it have
> a way to set a user keymap as the default? X has a very mature system
> for setting this, so I can have my custom keymapping everywhere except
> in editing the grub menu.  I've thought about buying a programmable
> ergonomic keyboard so this would no longer be an issue, but my current
> setup works.  Will it now work in Wayland?

It probably will not. Everything related to this is different, and there's
nothing as easy or as nice. You will probably want to select the X session
rather than the proposed new default.

[stan]

On Tue, 8 Sep 2020 17:48:30 -0400
Matthew Miller  wrote:
> On Tue, Sep 08, 2020 at 01:35:11PM -0700, stan via devel wrote:
> > Does it now have support for custom keymappings?  That is, does it
> > have a way to set a user keymap as the default? X has a very mature
> > system for setting this, so I can have my custom keymapping
> > everywhere except in editing the grub menu.  I've thought about
> > buying a programmable ergonomic keyboard so this would no longer be
> > an issue, but my current setup works.  Will it now work in Wayland?
>
> It probably will not. Everything related to this is different, and
> there's nothing as easy or as nice. You will probably want to select
> the X session rather than the proposed new default.

Thanks for the info.

[Tom Seewald]

Has anyone compiled a (non-exhaustive) list of known issues that are specific to KDE Plasma with Wayland? Are there currently any issues that would  block Wayland from becoming the default if they aren't resolved in time for F34?

[Julen Landa Alustiza]

20/9/9 05:30(e)an, Tom Seewald igorleak idatzi zuen:
> Has anyone compiled a (non-exhaustive) list of known issues that are specific to KDE Plasma with Wayland? Are there currently any issues that would  block Wayland from becoming the default if they aren't resolved in time for F34?

KDE spin is a blocker edition, so its default installation must pass our
release criterias.
https://fedoraproject.org/wiki/Fedora_Release_Criteria
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Tom Seewald]

> KDE
> spin is a blocker edition, so its default installation must pass our
> release criterias.
> https://fedoraproject.org/wiki/Fedora_Release_Criteria

Right, but have there been any investigations to see if those release criteria are fulfilled on Plasma + Wayland? If it doesn't currently meet all criteria, what are the known blockers?

[José Abílio Matos]

On Wednesday, September 9, 2020 4:30:54 AM WEST Tom Seewald wrote:
> Has anyone compiled a (non-exhaustive) list of known issues that are
> specific to KDE Plasma with Wayland?

https://community.kde.org/Plasma/Wayland_Showstoppers

[Neal Becker]

I have tested kde/wayland on F32 but have hit a roadblock.  We are all
working from home and need to share screens.  Using google chrome, on X11
when I
try to share an app window (which is my usual choice) there are no
problems, but on wayland only some of the windows are given as choices to
share.  I haven't
found any particular pattern to which windows are listed (is it just from
certain desktops?)  I believe this isn't chrome specific (have to retest).

Where can I report this issue?

Thanks,
Neal

On Wed, Sep 9, 2020 at 9:46 AM José Abílio Matos  wrote:
> On Wednesday, September 9, 2020 4:30:54 AM WEST Tom Seewald wrote:
> > Has anyone compiled a (non-exhaustive) list of known issues that are
> > specific to KDE Plasma with Wayland?
>
> https://community.kde.org/Plasma/Wayland_Showstoppers
>
> --
>
> José Abílio
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Neal Gompa]

On Wed, Sep 9, 2020 at 10:09 AM Neal Becker  wrote:
> I have tested kde/wayland on F32 but have hit a roadblock.  We are all working from home and need to share screens.  Using google chrome, on X11 when I
> try to share an app window (which is my usual choice) there are no problems, but on wayland only some of the windows are given as choices to share.  I haven't
> found any particular pattern to which windows are listed (is it just from certain desktops?)  I believe this isn't chrome specific (have to retest).
>
> Where can I report this issue?

Try here: https://bugs.kde.org/enter_bug.cgi?product=kwin&component=wayland-generi...

[Dominique Martinet]

Neal Becker wrote on Wed, Sep 09, 2020:
> I have tested kde/wayland on F32 but have hit a roadblock.  We are all
> working from home and need to share screens.  Using google chrome, on X11
> when I try to share an app window (which is my usual choice) there are no
> problems, but on wayland only some of the windows are given as choices to
> share.  I haven'tfound any particular pattern to which windows are
> listed (is it just from certain desktops?)  I believe this isn't
> chrome specific (have to retest).

I haven't tested but you can probaly only share other Xwayland windows
(chrome still runs on Xwayland last I checked)

The wayland-native way of sharing app windows is xdg-desktop-portal
which has a kde implementation:
https://invent.kde.org/plasma/xdg-desktop-portal-kde
https://koji.fedoraproject.org/koji/packageinfo?packageID=24326

Do you have xdg-desktop-portal-kde installed?
> Where can I report this issue?

Now that also needs to be supported by whatever videoconferencing
software you use (in this case chrome); you might want to try firefox
just to see if it's better...

So to sum it up:
 - if this works on FF but not chrome, it's a chrome bug
 - if this works on e.g. gnome with either browsers but not plasma, it's
a kde bug

Good luck (?)

[Neal Becker]

On Wed, Sep 9, 2020 at 10:33 AM Dominique Martinet 
wrote:
> Neal Becker wrote on Wed, Sep 09, 2020:
> > I have tested kde/wayland on F32 but have hit a roadblock.  We are all
> > working from home and need to share screens.  Using google chrome, on X11
> > when I try to share an app window (which is my usual choice) there are no
> > problems, but on wayland only some of the windows are given as choices to
> > share.  I haven'tfound any particular pattern to which windows are
> > listed (is it just from certain desktops?)  I believe this isn't
> > chrome specific (have to retest).
>
> I haven't tested but you can probaly only share other Xwayland windows
> (chrome still runs on Xwayland last I checked)
>
> The wayland-native way of sharing app windows is xdg-desktop-portal
> which has a kde implementation:
> https://invent.kde.org/plasma/xdg-desktop-portal-kde
> https://koji.fedoraproject.org/koji/packageinfo?packageID=24326
>
> Do you have xdg-desktop-portal-kde installed?

rpm -q xdg-desktop-portal-kde
xdg-desktop-portal-kde-5.19.5-1.fc32.x86_64

I tested firefox also, using google meet.  On firefox, no windows are
available to choose for sharing when run under wayland.  All the windows
show as expected
running firefox on plasma/X11.  That's a bit different than chrome but
seems to be some bug common between them.
>

[Vitaly Zaitsev]

On 08.09.2020 17:28, Ben Cotton wrote:
> Change the default session selection in SDDM to prefer the
> Wayland-based KDE Plasma Desktop session over the X11-based one.

KDE Plasma from F32 on Wayland has a major issue with broken keyboard
layout indicator. This issue need to be fixed first before making it
default.

[Christoph Karl]

Hello!

Me having this issue also.
But only in firefox and thunderbird, other appls seems to work.

Do you have a link, bugzilla or so?

Thank you

Best Regrads
Christoph

Am 09.09.20 um 16:51 schrieb Vitaly Zaitsev via devel:
> On 08.09.2020 17:28, Ben Cotton wrote:
> > Change the default session selection in SDDM to prefer the
> > Wayland-based KDE Plasma Desktop session over the X11-based one.
>
> KDE Plasma from F32 on Wayland has a major issue with broken keyboard
> layout indicator. This issue need to be fixed first before making it
> default.

[Vitaly Zaitsev]

On 09.09.2020 20:23, Christoph Karl wrote:
> Do you have a link, bugzilla or so?

https://bugs.kde.org/show_bug.cgi?id=390079

Known KDE-Wayland issues:
https://community.kde.org/Plasma/Wayland_Showstoppers

[John M. Harris Jr]

On Tuesday, September 8, 2020 8:28:20 AM MST 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: [e-mail], [e-mail], [e-mail]
> 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.
>
> -- 
> Ben Cotton
> He / Him / His
> Senior Program Manager, Fedora & CentOS Stream
> Red Hat
> TZ=America/Indiana/Indianapolis

As long as this can be fixed back to X11 on the systems where Wayland doesn't 
work (most), and the plasma-workspace-xorg package remains, I can't see any 
issue with this change. I'm sure it'd be great for people just getting into 
KDE, or people with newer hardware.

[Ondrej Mosnacek]

On Tue, Sep 8, 2020 at 5:30 PM 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: [e-mail], [e-mail], [e-mail]
> 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.

So yesterday I tried to log in to the KDE Plasma + Wayland session on
my laptop (F32) and the experience was unfortunately quite horrible...

1. When I logged out of the X session, switched to Wayland on the
login screen, and logged in, I only got a black screen. After I
rebooted, I managed to login to the Wayland session (I have automatic
login after boot enabled), but...
2. The desktop was all squeezed into a small 1024x786 rectangle in the
upper left corner of the screen (my screen is 1920x1080). So I opened
system settings to change the resolution, but...
3. The screen settings were showing "manufacturer_TODO" and
"model_TODO" as the name of the screen and the only resolution offered
was 1024x786.
4. The window layout of my KDE session was not preserved (I think even
the distribution of windows to activities was lost). But I probably
shouldn't expect this to work...
5. Logging out of the Wayland session gave me just a black screen with
blinking cursor, no login screen.

Reading the other posts in this thread it seems I'm the only one
experiencing such serious breakage (maybe except 4., which is
understandable), so I'm wondering if I did something wrong... I simply
installed plasma-workspace-wayland, logged out, and then logged in
selecting "Plasma (Wayland) (Wayland)" from the session dropdown.

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.

[Neal Becker]

Might be interesting to try logging in as a new user to see if some older
kde settings are messing things up.

On Thu, Sep 10, 2020 at 6:24 AM Ondrej Mosnacek  wrote:
> On Tue, Sep 8, 2020 at 5:30 PM 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: [e-mail], [e-mail], [e-mail]
> > 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.
>
> So yesterday I tried to log in to the KDE Plasma + Wayland session on
> my laptop (F32) and the experience was unfortunately quite horrible...
> When I logged out of the X session, switched to Wayland on the
>
> login screen, and logged in, I only got a black screen. After I
> rebooted, I managed to login to the Wayland session (I have automatic
> login after boot enabled), but...
> 2. The desktop was all squeezed into a small 1024x786 rectangle in the
> upper left corner of the screen (my screen is 1920x1080). So I opened
> system settings to change the resolution, but...
> 3. The screen settings were showing "manufacturer_TODO" and
> "model_TODO" as the name of the screen and the only resolution offered
> was 1024x786.
> 4. The window layout of my KDE session was not preserved (I think even
> the distribution of windows to activities was lost). But I probably
> shouldn't expect this to work...
> 5. Logging out of the Wayland session gave me just a black screen with
> blinking cursor, no login screen.
>
> Reading the other posts in this thread it seems I'm the only one
> experiencing such serious breakage (maybe except 4., which is
> understandable), so I'm wondering if I did something wrong... I simply
> installed plasma-workspace-wayland, logged out, and then logged in
> selecting "Plasma (Wayland) (Wayland)" from the session dropdown.
>
> --
> Ondrej Mosnacek
> Software Engineer, Platform Security - SELinux kernel
> Red Hat, Inc.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> Might be interesting to try logging in as a new user to see if some older kde settings are messing things up.

That's definitely possible... However this is a single-user machine
and I don't really feel like creating a new user :)

If I find some time I'll try it on my other laptop and/or dig deeper...
> On Thu, Sep 10, 2020 at 6:24 AM Ondrej Mosnacek  wrote:
> > On Tue, Sep 8, 2020 at 5:30 PM 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: [e-mail], [e-mail], [e-mail]
> > > 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.
> >
> > So yesterday I tried to log in to the KDE Plasma + Wayland session on
> > my laptop (F32) and the experience was unfortunately quite horrible...
> > When I logged out of the X session, switched to Wayland on the
> >
> > login screen, and logged in, I only got a black screen. After I
> > rebooted, I managed to login to the Wayland session (I have automatic
> > login after boot enabled), but...
> > 2. The desktop was all squeezed into a small 1024x786 rectangle in the
> > upper left corner of the screen (my screen is 1920x1080). So I opened
> > system settings to change the resolution, but...
> > 3. The screen settings were showing "manufacturer_TODO" and
> > "model_TODO" as the name of the screen and the only resolution offered
> > was 1024x786.
> > 4. The window layout of my KDE session was not preserved (I think even
> > the distribution of windows to activities was lost). But I probably
> > shouldn't expect this to work...
> > 5. Logging out of the Wayland session gave me just a black screen with
> > blinking cursor, no login screen.
> >
> > Reading the other posts in this thread it seems I'm the only one
> > experiencing such serious breakage (maybe except 4., which is
> > understandable), so I'm wondering if I did something wrong... I simply
> > installed plasma-workspace-wayland, logged out, and then logged in
> > selecting "Plasma (Wayland) (Wayland)" from the session dropdown.
> >
> > --
> > Ondrej Mosnacek
> > Software Engineer, Platform Security - SELinux kernel
> > Red Hat, Inc.
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
>
> --
> Those who don't understand recursion are doomed to repeat it
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Pavel Raiskup]

On Thursday, September 10, 2020 6:00:09 PM CEST Ondrej Mosnacek wrote:
> On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> > Might be interesting to try logging in as a new user to see if some older kde settings are messing things up.
>
> That's definitely possible... However this is a single-user machine
> and I don't really feel like creating a new user :)
>
> If I find some time I'll try it on my other laptop and/or dig deeper...

Ondrej, what Fedora version are you on?  The change claims:

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).

I'd consider a move to F34 just to test early, but even F34 still seems to
have 5.19.90.

The change says:

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.

Even a simple link to step-by-step howto would help.  How much sense does
it have to test F32/F33?

Pavel

[Ondrej Mosnacek]

On Mon, Sep 21, 2020 at 12:22 PM Pavel Raiskup  wrote:
> On Thursday, September 10, 2020 6:00:09 PM CEST Ondrej Mosnacek wrote:
> > On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> > > Might be interesting to try logging in as a new user to see if some older kde settings are messing things up.
> >
> > That's definitely possible... However this is a single-user machine
> > and I don't really feel like creating a new user :)
> >
> > If I find some time I'll try it on my other laptop and/or dig deeper...
>
> Ondrej, what Fedora version are you on?  The change claims:
>
> 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).
>
> I'd consider a move to F34 just to test early, but even F34 still seems to
> have 5.19.90.

I was trying it on F32. I was ready to see various annoyances, since
the proposal says that a lot of issues will be only fixed in F34, but
I hoped that in F32 the desktop will at least look normal when I log
in :)
> The change says:
> 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.
>
> Even a simple link to step-by-step howto would help.  How much sense does
> it have to test F32/F33?

Probably not much :) I was just curious to see how good/bad the
situation is currently on F32. From the optimistic wording in the
change request I imagined that most things already work and the latest
releases only fix some final annoyances... but maybe this is more true
about F33 than F32, or I just have some weirdness in my existing
configuration...

[Neal Gompa]

On Mon, Sep 21, 2020 at 7:11 AM Ondrej Mosnacek  wrote:
> On Mon, Sep 21, 2020 at 12:22 PM Pavel Raiskup  wrote:
> > On Thursday, September 10, 2020 6:00:09 PM CEST Ondrej Mosnacek wrote:
> > > On Thu, Sep 10, 2020 at 12:58 PM Neal Becker  wrote:
> > > > Might be interesting to try logging in as a new user to see if some older kde settings are messing things up.
> > >
> > > That's definitely possible... However this is a single-user machine
> > > and I don't really feel like creating a new user :)
> > >
> > > If I find some time I'll try it on my other laptop and/or dig deeper...
> >
> > Ondrej, what Fedora version are you on?  The change claims:
> >
> > 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).
> >
> > I'd consider a move to F34 just to test early, but even F34 still seems to
> > have 5.19.90.
>
> I was trying it on F32. I was ready to see various annoyances, since
> the proposal says that a lot of issues will be only fixed in F34, but
> I hoped that in F32 the desktop will at least look normal when I log
> in :)
> > The change says:
> > 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.
> >
> > Even a simple link to step-by-step howto would help.  How much sense does
> > it have to test F32/F33?
>
> Probably not much :) I was just curious to see how good/bad the
> situation is currently on F32. From the optimistic wording in the
> change request I imagined that most things already work and the latest
> releases only fix some final annoyances... but maybe this is more true
> about F33 than F32, or I just have some weirdness in my existing
> configuration...

I'm personally running Plasma Wayland on a couple of computers now on
Plasma 5.18 on Fedora 32. To do so, all you need to do is install
"plasma-workspace-wayland" and select the "Plasma (Wayland) (Wayland)
(Wayland)" session (yes really, the text is fixed with Plasma 5.19)
from the SDDM drop down.

You'll be missing all the remaining "basic" features implemented into
kwin-wayland like middle click paste and screencasting support, but
those will become available with Plasma 5.20. KDE upstream has a
specific "goal" to get Wayland support to first-class status:
https://community.kde.org/Goals/Wayland

My desire is to activate it as default in Rawhide as soon as possible
and start working with KDE upstream to hammer things out throughout
the entire development cycle for Fedora 34. We will probably wind up
shipping Plasma 5.21 or Plasma 5.22 for Fedora 34 GA, and getting
testing and such going as early as possible will help get the actual
target release for Fedora 34 in good shape for Plasma Wayland.

But of course, if by the time we get to beta freeze and it's too
buggy, we'll flip the default back to Xorg while shipping both as
options on the media and try again for Fedora 35.

[Vitaly Zaitsev]

On 21.09.2020 13:19, Neal Gompa wrote:
> KDE upstream has a
> specific "goal" to get Wayland support to first-class status:
> https://community.kde.org/Goals/Wayland

https://community.kde.org/Plasma/Wayland_Showstoppers

[Neal Gompa]

On Mon, Sep 21, 2020 at 8:28 AM Vitaly Zaitsev via devel
 wrote:
> On 21.09.2020 13:19, Neal Gompa wrote:
> > KDE upstream has a
> > specific "goal" to get Wayland support to first-class status:
> > https://community.kde.org/Goals/Wayland
>
> https://community.kde.org/Plasma/Wayland_Showstoppers

Okay, and? There's five months between now and beta freeze. Do you
seriously think that the bugs there won't get fixed? Some of them
already *have* been fixed in Plasma 5.19.

[Vitaly Zaitsev]

On 21.09.2020 14:30, Neal Gompa wrote:
> Do you
> seriously think that the bugs there won't get fixed? Some of them
> already *have* been fixed in Plasma 5.19.

A very annoying bug[1] with broken keyboard layout switcher must be a
blocker. Not everyone here lives in English-speaking countries.

[1]: https://bugs.kde.org/show_bug.cgi?id=390079

[Neal Gompa]

On Mon, Sep 21, 2020 at 9:05 AM Vitaly Zaitsev via devel
 wrote:
> On 21.09.2020 14:30, Neal Gompa wrote:
> > Do you
> > seriously think that the bugs there won't get fixed? Some of them
> > already *have* been fixed in Plasma 5.19.
>
> A very annoying bug[1] with broken keyboard layout switcher must be a
> blocker. Not everyone here lives in English-speaking countries.

Yes, I know of it. My systems have multiple languages activated too.
It works right now, but the indicator telling you which mode you're in
is broken at the moment.

--
真実はいつも一つ！/ Always, there's only one truth!

[Tom Seewald]

> Okay, and? There's five months between now and beta freeze. Do you
> seriously think that the bugs there won't get fixed? Some of them
> already *have* been fixed in Plasma 5.19.

It looks like most of the issues listed [1] still have open bug reports. Are these bug reports just not getting closed or are these problems not getting fixed?

[1] https://community.kde.org/Plasma/Wayland_Showstoppers

[Silvia Sánchez]

Ondrej,

You need to install Kwin Wayland and another package that will provide the
backend.
My experience wasn't the best, several apps crashed, effects stuttered or
were very slow, even typing felt slower.  But at least my desktop looked
normal.
One comment:  the logging out issue is not because of Wayland.  I have the
same with Xorg, and there are several bug reports pointing to the same
issue.

Kind regards,
Lailah

On Thu, 10 Sep 2020 at 12:24, Ondrej Mosnacek  wrote:
> On Tue, Sep 8, 2020 at 5:30 PM 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: [e-mail], [e-mail], [e-mail]
> > 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.
>
> So yesterday I tried to log in to the KDE Plasma + Wayland session on
> my laptop (F32) and the experience was unfortunately quite horrible...
> When I logged out of the X session, switched to Wayland on the
>
> login screen, and logged in, I only got a black screen. After I
> rebooted, I managed to login to the Wayland session (I have automatic
> login after boot enabled), but...
> 2. The desktop was all squeezed into a small 1024x786 rectangle in the
> upper left corner of the screen (my screen is 1920x1080). So I opened
> system settings to change the resolution, but...
> 3. The screen settings were showing "manufacturer_TODO" and
> "model_TODO" as the name of the screen and the only resolution offered
> was 1024x786.
> 4. The window layout of my KDE session was not preserved (I think even
> the distribution of windows to activities was lost). But I probably
> shouldn't expect this to work...
> 5. Logging out of the Wayland session gave me just a black screen with
> blinking cursor, no login screen.
>
> Reading the other posts in this thread it seems I'm the only one
> experiencing such serious breakage (maybe except 4., which is
> understandable), so I'm wondering if I did something wrong... I simply
> installed plasma-workspace-wayland, logged out, and then logged in
> selecting "Plasma (Wayland) (Wayland)" from the session dropdown.
>
> --
> Ondrej Mosnacek
> Software Engineer, Platform Security - SELinux kernel
> Red Hat, Inc.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 5:27 PM Silvia Sánchez  wrote:
> Ondrej,
>
> You need to install Kwin Wayland and another package that will provide the backend.

It seems all the necessary packages were pulled in as dependencies via
plasma-workspace-wayland.

$ sudo dnf info --installed *wayland* | grep Name
Name         : kf5-kwayland
Name         : kwayland-integration
Name         : kwin-wayland
Name         : libwayland-client
Name         : libwayland-client
Name         : libwayland-cursor
Name         : libwayland-cursor
Name         : libwayland-egl
Name         : libwayland-egl
Name         : libwayland-server
Name         : libwayland-server
Name         : plasma-workspace-wayland
Name         : qt5-qtwayland
Name         : qt5-qtwayland-devel
Name         : xorg-x11-server-Xwayland

Looking at the available but not installed packages that match
*wayland* I don't see any that would be relevant.
> My experience wasn't the best, several apps crashed, effects stuttered or were very slow, even typing felt slower.  But at least my desktop looked normal.
> One comment:  the logging out issue is not because of Wayland.  I have the same with Xorg, and there are several bug reports pointing to the same issue.

Oh, thanks for the info! So I guess the only Wayland issue for me so
far is the messed up resolution/screen settings. Once I get past that
I'll probably see the "normal" known issues, too :)
> Kind regards,
> Lailah
>
> On Thu, 10 Sep 2020 at 12:24, Ondrej Mosnacek  wrote:
> > On Tue, Sep 8, 2020 at 5:30 PM 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: [e-mail], [e-mail], [e-mail]
> > > 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.
> >
> > So yesterday I tried to log in to the KDE Plasma + Wayland session on
> > my laptop (F32) and the experience was unfortunately quite horrible...
> > When I logged out of the X session, switched to Wayland on the
> >
> > login screen, and logged in, I only got a black screen. After I
> > rebooted, I managed to login to the Wayland session (I have automatic
> > login after boot enabled), but...
> > 2. The desktop was all squeezed into a small 1024x786 rectangle in the
> > upper left corner of the screen (my screen is 1920x1080). So I opened
> > system settings to change the resolution, but...
> > 3. The screen settings were showing "manufacturer_TODO" and
> > "model_TODO" as the name of the screen and the only resolution offered
> > was 1024x786.
> > 4. The window layout of my KDE session was not preserved (I think even
> > the distribution of windows to activities was lost). But I probably
> > shouldn't expect this to work...
> > 5. Logging out of the Wayland session gave me just a black screen with
> > blinking cursor, no login screen.
> >
> > Reading the other posts in this thread it seems I'm the only one
> > experiencing such serious breakage (maybe except 4., which is
> > understandable), so I'm wondering if I did something wrong... I simply
> > installed plasma-workspace-wayland, logged out, and then logged in
> > selecting "Plasma (Wayland) (Wayland)" from the session dropdown.
> >
> > --
> > Ondrej Mosnacek
> > Software Engineer, Platform Security - SELinux kernel
> > Red Hat, Inc.
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Kevin Kofler]

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: [e-mail], [e-mail], [e-mail]
> 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.

I do not think that Plasma on Wayland is ready for production use at this 
time. E.g., middle-click paste support is still incomplete: interoperability 
of the feature with X11 and GTK applications is not working yet. (X11 
because the XWayland parts of the middle-click feature are not yet 
implemented in KWin-Wayland, GTK because KWin supports only the final 
standardized version of the extension whereas GTK apparently still only 
implements its own pre-standard version with a differently-named namespace.) 
I believe that there are also other open issues with Plasma on Wayland.

Kevin Kofler

[Sérgio Basto]

On Mon, 2020-09-14 at 00:46 +0200, Kevin Kofler wrote:
> 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: [e-mail], [e-mail], [e-mail]
> > 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.
>
> I do not think that Plasma on Wayland is ready for production use at
> this 
> time. E.g., middle-click paste support is still incomplete:
> interoperability 
> of the feature with X11 and GTK applications is not working yet.
> (X11 
> because the XWayland parts of the middle-click feature are not yet 
> implemented in KWin-Wayland, GTK because KWin supports only the
> final 
> standardized version of the extension whereas GTK apparently still
> only 
> implements its own pre-standard version with a differently-named
> namespace.) 
> I believe that there are also other open issues with Plasma on
> Wayland.

Can we revert this decision, seems almost all the people have the same
opinion ... that Plasma on Wayland is not ready for production.
IMHO, try run it in wayland should be a optin .

We have been aware of the wayland induced issues for a couple of years.
The fedora kde/qt team are aware of the issues wayland causes and just
blame the apps.

https://lists.fedoraproject.org/archives/list/[e-mail]/th...

Also, I'm against add workarounds on desktop files like this one [1]
forcing apps running with QT_QPA_PLATFORM=xcb , because is just hidden
the real problem.

Note upstream app developers can opt by not support wayland and
internally force use of X11, but we shouldn't do that on desktop files
because app could be called  by other method ...

[1] 
https://pkgs.rpmfusion.org/cgit/free/shotcut.git/commit/?id=72db606a7e307e51...

https://pkgs.rpmfusion.org/cgit/free/shotcut.git/tree/Force_X.patch

[Vitaly Zaitsev]

On 28.12.2020 11:54, Sérgio Basto wrote:
> Also, I'm against add workarounds on desktop files like this one [1]
> forcing apps running with QT_QPA_PLATFORM=xcb , because is just hidden
> the real problem.

Instead of patching, Qt5 maintainers should drop this patch[1].

[1]: 
https://src.fedoraproject.org/rpms/qt5-qtbase/blob/master/f/qtbase-use-wayla...
[2]: https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome
[3]: https://bugreports.qt.io/browse/QTBUG-88293

[Rex Dieter]

Sérgio Basto wrote:
> On Mon, 2020-09-14 at 00:46 +0200, Kevin Kofler wrote:
> > 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.
> Can we revert this decision, seems almost all the people have the same
> opinion ... that Plasma on Wayland is not ready for production.
> IMHO, try run it in wayland should be a optin .

This can't be fully appreciated until plasma-5.21 lands.  No formal 
decisions will be made until at least then.

And until then, if there are any issues you want to be considered blocking, 
please file bugs.  Currently I see nothing blocking the tracker
https://bugzilla.redhat.com/show_bug.cgi?id=1882465
> Also, I'm against add workarounds on desktop files like this one [1]
> forcing apps running with QT_QPA_PLATFORM=xcb , because is just hidden
> the real problem.

...
> Note upstream app developers can opt by not support wayland and
> internally force use of X11, but we shouldn't do that on desktop files
> because app could be called  by other method ...

That's related, but different.  However, applications will have to adapt 
sooner or later, may as well be sooner.

-- Rex

[Gerald B. Cox]

I really don't see we have much of a choice here.  X11 is eventually going away and Wayland is the path forward.  That's already been decided, so at this point it isn't a matter for debate.  Human nature being what it is, people tend to procrastinate and not do anything until pressed up against a deadline - so here we are.  Wayland has been discussed for over a decade now, so this shouldn't be a surprise to anyone.  I've been opening bugs whenever I see issues, so upstream, packagers and end users are aware of the issue.  If I know of a workaround or alternative that works, I list it.  There is currently an open issue with a black screen and SDDM in conjunction with Radeon graphics.  In my opinion, if this isn't resolved, we should switch to GDM rather than delay making Wayland the default.  If a particular application doesn't work in Wayland, we should advise people of alternatives rather than holding this change hostage.  I've seen great improvements between 5.19 and 5.20 - and 5.2
 1 promises more.  So if you haven't tried wayland and plasma lately - you should try again.

If you notice issues, please open bugs.

[Fulko Hew]

On Mon, Dec 28, 2020 at 3:51 PM Gerald B. Cox  wrote:

... snip ...

So if you haven't tried wayland and plasma lately - you should try again.
>

OK.
a) is there an easy (i.e. documented) way of testing it?
b) is there an equivalent to 'remoting' single windows (applications)
   to remote machines? ie. export DISPLAY=... or ssh -x ...

[Rex Dieter]

Fulko Hew wrote:
> a) is there an easy (i.e. documented) way of testing it?

Keeping in mind that testing anything now (before plasma 5.21 is 
preliminary), but... best way to test:

1.  create a new user for testing purposes
2.  make sure plasma-workspace-wayland pkg is installed
3.  login using Desktop Session: Plasma (wayland)

-- Rex

[przemek klosowski]

On 12/28/20 3:51 PM, Gerald B. Cox wrote:
> I really don't see we have much of a choice here.  X11 is eventually going away and Wayland is the path forward.

...
> If you notice issues, please open bugs.

I have an open bz about reliable wayland crashes:

https://bugzilla.redhat.com/show_bug.cgi?id=1539992

Besides being very inconvenient because of course they take the entire 
session with it, such crashes can usually be leveraged to achieve code 
execution, and if the behavior can be triggered by remote data, RCEs. 
Therefore, I would argue it is a serious issue.

Basically, the crash is triggered by excessive resource usage that can 
be seen via xrestop. Unfortunately I was unable to debug the issue: the 
GTK+  forest overwhelmed my capabilities ('callbacks, callbacks, 
everywhere').

This is an old bug currently assigned to gnome-session. Should I 
reassign it to Wayland?

[Michael Catanzaro]

On Tue, Dec 29, 2020 at 5:01 pm, przemek klosowski via devel 
 wrote:
> This is an old bug currently assigned to gnome-session. Should I
> reassign it to Wayland?

Please don't. That is an X11-specific bug; you can see the top 10 
frames of the backtrace are all X11 code. I will reassign it to mutter, 
but if you want it to actually get fixed, you should really report it 
upstream, because the chances of it attracting attention on Red Hat 
Bugzilla are slim. I recommend you only report GNOME bugs downstream if 
you've found a downstream packaging issue or if you need the downstream 
bug for blocker or freeze exception process.

I don't think this GNOME bug is in any way related to the topic of 
whether KDE should default to Wayland....

[przemek klosowski]

On 12/29/20 5:20 PM, Michael Catanzaro wrote:
> I don't think this GNOME bug is in any way related to the topic of 
> whether KDE should default to Wayland....

So I am confused---I thought it is a problem in Wayland, perhaps in its 
X11 emulation but still Wayland.  Yes, the app is misbehaving, but 
Wayland should be resistant to this 'fuzzing'.

Re, this being the GNOME bug, I think any app with this behavior will 
similarly crash wayland even if it is not GTK app, and regardless 
whether it's running under KDE or Gnome---but I was not able to 
understand the GTK app enough to write a minimal replication.

Perhaps you are implying that when Wayland is the only choice, X11 
applications will be replaced by wayland apps and the X11 emulation will 
be removed form Wayland, so this will no longer be an issue?

I thought I checked that the 'true' X11 server does not crash in this 
scenario,  but I realize now that I am not sure.

BTW, I did report this in Gnome as well 
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/9

[Samuel Sieb]

On 12/29/20 4:25 PM, przemek klosowski via devel wrote:
> On 12/29/20 5:20 PM, Michael Catanzaro wrote:
> > I don't think this GNOME bug is in any way related to the topic of 
> > whether KDE should default to Wayland....
>
> So I am confused---I thought it is a problem in Wayland, perhaps in its 
> X11 emulation but still Wayland.  Yes, the app is misbehaving, but 
> Wayland should be resistant to this 'fuzzing'.

More likely what you're really confused about is something that a lot of 
people are not aware of.  Wayland is a protocol, not a program.  I 
believe there's a library, but the final implementation is done in each 
window manager.  The X11 "emulation" is a program called XWayland that 
provides an interface layer between the X11 calls and whatever Wayland 
implementation is currently running.

[przemek klosowski]

On 12/29/20 11:26 PM, Samuel Sieb wrote:
> More likely what you're really confused about is something that a lot 
> of people are not aware of.  Wayland is a protocol, not a program.  I 
> believe there's a library, but the final implementation is done in 
> each window manager.  The X11 "emulation" is a program called XWayland 
> that provides an interface layer between the X11 calls and whatever 
> Wayland implementation is currently running.

Thanks for clarifying; indeed it's the XWayland process that crashes.

I actually support leaving X11 behind---I use wayland myself and I agree 
it's the correct evolutionary path for system graphics.

I piped up in this discussion to point out that Wayland has rough 
spots.  There are many legacy X11 apps still around, some possibly 
buggy. They should not crash XWayland in a way that nukes the entire 
desktop.

Another problem is the reliability of input streams. The mouse behavior 
is realy weird sometimes, as if it was simultaneously losing events and 
getting spurious ones.

I suspect that these issues are marginal enough to not affect the 
majority of users, which is why they aren't seen as urgent, but I think 
they should be addressed for a mainstream Wayland use. I would like to 
help debugging that, but it's a complex system and I wasn't able to find 
reliable information on how to look inside those issues. For instance, I 
understand the separation of layers in X11, and I know how to debug X11 
events using xev and such---but I have no idea how to look into why my 
mouse clicks in Firefox under Wayland are so weird and unpredictable.