Please remove the xwayland ("Wayland") and wayland ("Full Wayland") sessions as we know them
Dear all, Over the past months I've run into multiple bugs on both "wayland sessions" shipped by default by Tumbleweed (Leap uses the same settings so it's in the same boat as far as I can tell) which I was never running into on two other Linux distributions (i.e. NixOS and Fedora). This caught my attention and after back and forth discussions with Plasma developers and members of the oS community, this conclusion has become inescapable: most of these bugs are not just facilitated, but outright *caused* by certain settings that the package maintainer(s) of the Plasma desktop have decided to apply, against the recommendations of the Plasma developers. If like me a couple of days ago you aren't familiar with this topic, the issue revolves around two environmental variables which our Plasma packagers have decided to override: - GDK_BACKEND: our xwayland session (displayed as "Plasma Wayland" in SDDM) is built with a patch overriding its value to "xcb", while our wayland session (displayed as "Plasma Full Wayland in SDDM) overrides it to "wayland" - QT_QPA_PLATFORM: overriden to "xcb;wayland" and "wayland;xcb" in the two sessions respectively. Both variables are read at runtime to control the choice of a display client by GTK and Qt apps, as their name suggests. In this instance our xwayland session forces GTK apps to use an X11 client, whereas our wayland ("Full Wayland") session forces them to use a Wayland client. As for Qt apps, xwayland forces them to use an X11 client -- with a fallback on a wayland client -- while wayland ("Full Wayland") does things vice-versa -- forces them to use a wayland client, with a fallback on X11. Now for the issue: roughly put, the issue is that the decision to override these values corners users in an impossible dilemma. To appreciate the dilemma, we can consider two widely used sets of applications: a. recent, well-maintained Qt/GKT native applications installed from official .RPM packages (typically: Kate, Konsole, Kwin); and b. flatpak-ed, apps using either slightly outdated GTK libraries or based on the Electron stack (~ most of the flatpaks) If the user picks xwayland, several apps in (a) will run into issues. The reason is that KDE developers, in the course of migrating their code base to the wayland compositing protocol, have made substantial efforts to make these applications play nice with a wayland client, and pushing these applications in the reverse direction is likely to introduce regressions, to escape test coverage and make it very, very difficult for the end user to get troubleshooting and support from KDE. While if the user picks wayland ("Full Wayland"), the (a)-applications will run fine but the (b)-applications will be very buggy, and most of them will just refuse to launch. And by the way it's very easy for you to test both horns of the dilemma. That's simply a cherry-picked example, but it's not difficult to come up with more: try making a custom, rectangular capture using Spectacle in xwayland (this will fail because the program was built with the idea that it would output to wayland, not X11); or try launching something like the OBS Studio flatpak in wayland ("Full Wayland"). Until yesterday I thought that the solution to this pain was to use a different choice of values for GDK_BACKEND and QT_QPA_PLATFORM, setting them for example to "xcb" and "wayland;xcb", building on the assumption that Qt apps need wayland and that Gtk apps are compatible with X11. But in fact we don't *need* at all to find any particular combination of values, because as other members of the community pointed out, both Gtk and Qt apps are perfectly able to find their way to their preferred display client. So the best course of action is simply to not force any particular value down their throat, which as far as I know boils down to simply removing the xwayland and wayland ("Full wayland") sessions, replacing them with a session in line with upstream, which does not bake these values into their plasma desktop builds. To me the situation can be summarized by: we're altering the plasma desktop from upstream, sending to library and application developers a message that is more or less "we don't care what you guys think your programs should display to, because we at oS know better". This message would be tolerable if it secured the best for our users, but as I've tried to suggest, that's not the case. Not only are our users going to have a flawed perception of the Plasma desktop, because it behaves too rogue to express the intent of upstream, but we are making it unnecessarily difficult for our users to get decent troubleshooting, because no other distribution does it our way. That means a much smaller user pool to draw from when troubleshooting our users, and requires that our users remember to warn people at bugs triage that they're using a *special plasma config*. I've reached out yesterday to Fabian Vogt -- one of the maintainers of our plasma desktop package -- on these matters, and so far he has been helpful and open-minded. I certainly don't want to arm-wrestle him over this mailing list. Instead I am trying to fulfill his demand for more user feedback. Best, Adrien
Thank you, Adrien! I was bugged by this for a while. Is not critical yet since I am forced to use "enterprise" applications that are able to run only on x11 or need two vestals to hit enter on 15th of june to run on wayland. Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Mon, 8 Mar 2021 at 10:09, Adrien Glauser <adrien.glauser@gmail.com> wrote:
Dear all,
Over the past months I've run into multiple bugs on both "wayland sessions" shipped by default by Tumbleweed (Leap uses the same settings so it's in the same boat as far as I can tell) which I was never running into on two other Linux distributions (i.e. NixOS and Fedora). This caught my attention and after back and forth discussions with Plasma developers and members of the oS community, this conclusion has become inescapable: most of these bugs are not just facilitated, but outright *caused* by certain settings that the package maintainer(s) of the Plasma desktop have decided to apply, against the recommendations of the Plasma developers.
If like me a couple of days ago you aren't familiar with this topic, the issue revolves around two environmental variables which our Plasma packagers have decided to override: - GDK_BACKEND: our xwayland session (displayed as "Plasma Wayland" in SDDM) is built with a patch overriding its value to "xcb", while our wayland session (displayed as "Plasma Full Wayland in SDDM) overrides it to "wayland" - QT_QPA_PLATFORM: overriden to "xcb;wayland" and "wayland;xcb" in the two sessions respectively.
Both variables are read at runtime to control the choice of a display client by GTK and Qt apps, as their name suggests. In this instance our xwayland session forces GTK apps to use an X11 client, whereas our wayland ("Full Wayland") session forces them to use a Wayland client. As for Qt apps, xwayland forces them to use an X11 client -- with a fallback on a wayland client -- while wayland ("Full Wayland") does things vice-versa -- forces them to use a wayland client, with a fallback on X11.
Now for the issue: roughly put, the issue is that the decision to override these values corners users in an impossible dilemma. To appreciate the dilemma, we can consider two widely used sets of applications: a. recent, well-maintained Qt/GKT native applications installed from official .RPM packages (typically: Kate, Konsole, Kwin); and b. flatpak-ed, apps using either slightly outdated GTK libraries or based on the Electron stack (~ most of the flatpaks)
If the user picks xwayland, several apps in (a) will run into issues. The reason is that KDE developers, in the course of migrating their code base to the wayland compositing protocol, have made substantial efforts to make these applications play nice with a wayland client, and pushing these applications in the reverse direction is likely to introduce regressions, to escape test coverage and make it very, very difficult for the end user to get troubleshooting and support from KDE. While if the user picks wayland ("Full Wayland"), the (a)-applications will run fine but the (b)-applications will be very buggy, and most of them will just refuse to launch.
And by the way it's very easy for you to test both horns of the dilemma. That's simply a cherry-picked example, but it's not difficult to come up with more: try making a custom, rectangular capture using Spectacle in xwayland (this will fail because the program was built with the idea that it would output to wayland, not X11); or try launching something like the OBS Studio flatpak in wayland ("Full Wayland").
Until yesterday I thought that the solution to this pain was to use a different choice of values for GDK_BACKEND and QT_QPA_PLATFORM, setting them for example to "xcb" and "wayland;xcb", building on the assumption that Qt apps need wayland and that Gtk apps are compatible with X11. But in fact we don't *need* at all to find any particular combination of values, because as other members of the community pointed out, both Gtk and Qt apps are perfectly able to find their way to their preferred display client. So the best course of action is simply to not force any particular value down their throat, which as far as I know boils down to simply removing the xwayland and wayland ("Full wayland") sessions, replacing them with a session in line with upstream, which does not bake these values into their plasma desktop builds.
To me the situation can be summarized by: we're altering the plasma desktop from upstream, sending to library and application developers a message that is more or less "we don't care what you guys think your programs should display to, because we at oS know better". This message would be tolerable if it secured the best for our users, but as I've tried to suggest, that's not the case. Not only are our users going to have a flawed perception of the Plasma desktop, because it behaves too rogue to express the intent of upstream, but we are making it unnecessarily difficult for our users to get decent troubleshooting, because no other distribution does it our way. That means a much smaller user pool to draw from when troubleshooting our users, and requires that our users remember to warn people at bugs triage that they're using a *special plasma config*.
I've reached out yesterday to Fabian Vogt -- one of the maintainers of our plasma desktop package -- on these matters, and so far he has been helpful and open-minded. I certainly don't want to arm-wrestle him over this mailing list. Instead I am trying to fulfill his demand for more user feedback.
Best,
Adrien
I'm always looking forward to the improvements from KDE to get a better Wayland experience, but somehow it has always fell short. Users of other distros keep mentioning how much better and better it gets while I don't see the same happening on openSUSE. I had the issue where Flatpaks on Full Wayland not even launched. Now I know why so thanks for the investigation, Adrien! Could this patch be removed so we can get a proper Plasma Wayland experience?
Op maandag 8 maart 2021 15:01:54 CET schreef Attila Pinter:
I'm always looking forward to the improvements from KDE to get a better Wayland experience, but somehow it has always fell short. Users of other distros keep mentioning how much better and better it gets while I don't see the same happening on openSUSE. I had the issue where Flatpaks on Full Wayland not even launched. Now I know why so thanks for the investigation, Adrien! Could this patch be removed so we can get a proper Plasma Wayland experience? Same thoughts here. Tried the (x)wayland plasma sessions but always ran into issues, never had and took the time to dive in deeper. Thanks for doing that, Adrien.
-- Gertjan Lettink a.k.a. Knurpht openSUSE Board openSUSE Forums Team
I'm always looking forward to the improvements from KDE to get a better Wayland experience, but somehow it has always fell short. Users of other distros keep mentioning how much better and better it gets while I don't see the same happening on openSUSE. I had the issue where Flatpaks on Full Wayland not even launched. Now I know why so thanks for the investigation, Adrien! Could this patch be removed so we can get a proper Plasma Wayland experience? I concur with the above. Some months ago I tried to use some of the wayland sessions, but even the simplest task did not work as expected. I experienced crashes and/or malformed windows. I do not remember much
On 08/03/2021 15:01, Attila Pinter wrote: details, but it have me decided to ignore the waylands for some time longer and remove as much as possible wayland related stuff as possible. Maybe the mentioned settings where to blame, and since I have no time or motivation to investigate the encountered issues, I just stick to what is working, the default Plasma setting. --- Frans.
Hi, there are some misunderstandings and misconceptions in this mail and the replies. I don't have the time to clear those up in depth right now, so I hope that there's enough info in this thread: https://lists.opensuse.org/archives/list/kde@lists.opensuse.org/message/BIWK... It's a link to a poll on this topic from half a year ago on [os-kde], where I also explained the background. tl;dr: It exists for an easier transition to using Plasma with Wayland, to work around certain shortcomings (middle-click paste, application interop) and bugs (KMail/WebEngine on Wayland. If those shortcomings are no longer there or no longer relevant to the target group (recent/current users of the X11 sessions), then the deviation from upstream defaults served their purpose and can be retired. Input from users is needed for that, to ensure that it doesn't introduce any regressions which force them away from the Wayland sessions again. The alternative is to do a scream test: Switch the defaults and see whether someone complains. I'm not opposed to either of those and would prefer a combination: Ask for feedback from testers, and if it's not enough, do the scream test. I'm more than happy to drop this, if it's the right time. Am Montag, 8. März 2021, 11:08:59 CET schrieb Adrien Glauser:
Dear all,
Over the past months I've run into multiple bugs on both "wayland sessions" shipped by default by Tumbleweed (Leap uses the same settings so it's in the same boat as far as I can tell) which I was never running into on two other Linux distributions (i.e. NixOS and Fedora). This caught my attention and after back and forth discussions with Plasma developers and members of the oS community, this conclusion has become inescapable: most of these bugs are not just facilitated, but outright *caused* by certain settings that the package maintainer(s) of the Plasma desktop have decided to apply, against the recommendations of the Plasma developers.
It has to be noted that "package maintainers" and "Plasma developers" are not two disjoined groups. The Qt Wayland QPA has known issues, and it actually disables itself by default in a GNOME session for those reasons and uses xcb instead.
If like me a couple of days ago you aren't familiar with this topic, the issue revolves around two environmental variables which our Plasma packagers have decided to override: - GDK_BACKEND: our xwayland session (displayed as "Plasma Wayland" in SDDM) is built with a patch overriding its value to "xcb", while our wayland session (displayed as "Plasma Full Wayland in SDDM) overrides it to "wayland" - QT_QPA_PLATFORM: overriden to "xcb;wayland" and "wayland;xcb" in the two sessions respectively.
The "Plasma (Wayland)" session does not override QT_QPA_PLATFORM.
Both variables are read at runtime to control the choice of a display client by GTK and Qt apps, as their name suggests. In this instance our xwayland session forces GTK apps to use an X11 client, whereas our wayland ("Full Wayland") session forces them to use a Wayland client. As for Qt apps, xwayland forces them to use an X11 client -- with a fallback on a wayland client -- while wayland ("Full Wayland") does things vice-versa -- forces them to use a wayland client, with a fallback on X11.
Now for the issue: roughly put, the issue is that the decision to override these values corners users in an impossible dilemma. To appreciate the dilemma, we can consider two widely used sets of applications: a. recent, well-maintained Qt/GKT native applications installed from official .RPM packages (typically: Kate, Konsole, Kwin); and b. flatpak-ed, apps using either slightly outdated GTK libraries or based on the Electron stack (~ most of the flatpaks)
If the user picks xwayland, several apps in (a) will run into issues. The reason is that KDE developers, in the course of migrating their code base to the wayland compositing protocol, have made substantial efforts to make these applications play nice with a wayland client, and pushing these applications in the reverse direction is likely to introduce regressions, to escape test coverage and make it very, very difficult for the end user to get troubleshooting and support from KDE. While if the user picks wayland ("Full Wayland"), the (a)-applications will run fine but the (b)-applications will be very buggy, and most of them will just refuse to launch.
And by the way it's very easy for you to test both horns of the dilemma. That's simply a cherry-picked example, but it's not difficult to come up with more: try making a custom, rectangular capture using Spectacle in xwayland (this will fail because the program was built with the idea that it would output to wayland, not X11); or try launching something like the OBS Studio flatpak in wayland ("Full Wayland").
Until yesterday I thought that the solution to this pain was to use a different choice of values for GDK_BACKEND and QT_QPA_PLATFORM, setting them for example to "xcb" and "wayland;xcb", building on the assumption that Qt apps need wayland and that Gtk apps are compatible with X11. But in fact we don't *need* at all to find any particular combination of values, because as other members of the community pointed out, both Gtk and Qt apps are perfectly able to find their way to their preferred display client. So the best course of action is simply to not force any particular value down their throat, which as far as I know boils down to simply removing the xwayland and wayland ("Full wayland") sessions, replacing them with a session in line with upstream, which does not bake these values into their plasma desktop builds.
To me the situation can be summarized by: we're altering the plasma desktop from upstream, sending to library and application developers a message that is more or less "we don't care what you guys think your programs should display to, because we at oS know better". This message would be tolerable if it secured the best for our users, but as I've tried to suggest, that's not the case. Not only are our users going to have a flawed perception of the Plasma desktop, because it behaves too rogue to express the intent of upstream, but we are making it unnecessarily difficult for our users to get decent troubleshooting, because no other distribution does it our way. That means a much smaller user pool to draw from when troubleshooting our users, and requires that our users remember to warn people at bugs triage that they're using a *special plasma config*.
I've reached out yesterday to Fabian Vogt -- one of the maintainers of our plasma desktop package -- on these matters, and so far he has been helpful and open-minded. I certainly don't want to arm-wrestle him over this mailing list. Instead I am trying to fulfill his demand for more user feedback.
The right way to do that is by asking in an "unbiased" mail, because only then replies can be based on an informed decision. This mail doesn't fit that criteria unfortunately. It also omits the reasons why this split between the two Wayland session types was introduced in the first place. Cheers, Fabian
Best,
Adrien
Thank for correcting this imprecision of mine: indeed in the "Full Wayland" session, QT_QPA_PLATFORM seems to be kept to the value it is set to upstream, "wayland", and not as I wrote above, to "wayland;xcb". To summarize for anyone reading this: - GDK_BACKEND (Xwayland): set to xcb - QT_QPA_PLATFORM (Xwayland): set to xcb - GDK_BACKEND (Full Wayland): set to wayland - QT_QPA_PLATFORM (Full Wayland): set to wayland - GDK_BACKEND (upstream): unset - QT_QPA_PLATFORM (upstream): set to wayland I am arguing for doing things the way upstream does, which Fabian is willing to do but only if we get more user feedback. I'll be working with him off the list on the details of how to gather feedback in a way acceptable to him, but any suggestion or comment is welcome. Will update this thread when appropriate.
Oups pressed the wrong button and the first part of my reply to Fabian was not CC'ed to the list: 8<-------------------------- Dear Fabian, Thanks for your email, I appreciate. I've checked out the thread you mention as a poll. I see only 1 reply there. Where can I see the other replies -- if possible those that specifically address the question, because you're asking two separate questions in that poll? Who are the "testers" you refer me to? (Sorry I've been a member of oS since last summer, and I don't know who they are). And again, isn't asking for their feedback replaying the same issue (i.e. bias control) in a different context? Finally did you apply the same measures for extracting unbiased feedback when you or your predecessor introduced this patching? Cheers, Adrien Le 09/03/2021 à 10:35, Fabian Vogt a écrit :
Hi,
there are some misunderstandings and misconceptions in this mail and the replies. I don't have the time to clear those up in depth right now, so I hope that there's enough info in this thread: https://lists.opensuse.org/archives/list/kde@lists.opensuse.org/message/BIWK... It's a link to a poll on this topic from half a year ago on [os-kde], where I also explained the background.
tl;dr: It exists for an easier transition to using Plasma with Wayland, to work around certain shortcomings (middle-click paste, application interop) and bugs (KMail/WebEngine on Wayland. If those shortcomings are no longer there or no longer relevant to the target group (recent/current users of the X11 sessions), then the deviation from upstream defaults served their purpose and can be retired.
Input from users is needed for that, to ensure that it doesn't introduce any regressions which force them away from the Wayland sessions again.
The alternative is to do a scream test: Switch the defaults and see whether someone complains.
I'm not opposed to either of those and would prefer a combination: Ask for feedback from testers, and if it's not enough, do the scream test. I'm more than happy to drop this, if it's the right time.
Am Montag, 8. März 2021, 11:08:59 CET schrieb Adrien Glauser:
Dear all,
Over the past months I've run into multiple bugs on both "wayland sessions" shipped by default by Tumbleweed (Leap uses the same settings so it's in the same boat as far as I can tell) which I was never running into on two other Linux distributions (i.e. NixOS and Fedora). This caught my attention and after back and forth discussions with Plasma developers and members of the oS community, this conclusion has become inescapable: most of these bugs are not just facilitated, but outright *caused* by certain settings that the package maintainer(s) of the Plasma desktop have decided to apply, against the recommendations of the Plasma developers.
It has to be noted that "package maintainers" and "Plasma developers" are not two disjoined groups.
The Qt Wayland QPA has known issues, and it actually disables itself by default in a GNOME session for those reasons and uses xcb instead.
If like me a couple of days ago you aren't familiar with this topic, the issue revolves around two environmental variables which our Plasma packagers have decided to override: - GDK_BACKEND: our xwayland session (displayed as "Plasma Wayland" in SDDM) is built with a patch overriding its value to "xcb", while our wayland session (displayed as "Plasma Full Wayland in SDDM) overrides it to "wayland" - QT_QPA_PLATFORM: overriden to "xcb;wayland" and "wayland;xcb" in the two sessions respectively.
The "Plasma (Wayland)" session does not override QT_QPA_PLATFORM.
Both variables are read at runtime to control the choice of a display client by GTK and Qt apps, as their name suggests. In this instance our xwayland session forces GTK apps to use an X11 client, whereas our wayland ("Full Wayland") session forces them to use a Wayland client. As for Qt apps, xwayland forces them to use an X11 client -- with a fallback on a wayland client -- while wayland ("Full Wayland") does things vice-versa -- forces them to use a wayland client, with a fallback on X11.
Now for the issue: roughly put, the issue is that the decision to override these values corners users in an impossible dilemma. To appreciate the dilemma, we can consider two widely used sets of applications: a. recent, well-maintained Qt/GKT native applications installed from official .RPM packages (typically: Kate, Konsole, Kwin); and b. flatpak-ed, apps using either slightly outdated GTK libraries or based on the Electron stack (~ most of the flatpaks)
If the user picks xwayland, several apps in (a) will run into issues. The reason is that KDE developers, in the course of migrating their code base to the wayland compositing protocol, have made substantial efforts to make these applications play nice with a wayland client, and pushing these applications in the reverse direction is likely to introduce regressions, to escape test coverage and make it very, very difficult for the end user to get troubleshooting and support from KDE. While if the user picks wayland ("Full Wayland"), the (a)-applications will run fine but the (b)-applications will be very buggy, and most of them will just refuse to launch.
And by the way it's very easy for you to test both horns of the dilemma. That's simply a cherry-picked example, but it's not difficult to come up with more: try making a custom, rectangular capture using Spectacle in xwayland (this will fail because the program was built with the idea that it would output to wayland, not X11); or try launching something like the OBS Studio flatpak in wayland ("Full Wayland").
Until yesterday I thought that the solution to this pain was to use a different choice of values for GDK_BACKEND and QT_QPA_PLATFORM, setting them for example to "xcb" and "wayland;xcb", building on the assumption that Qt apps need wayland and that Gtk apps are compatible with X11. But in fact we don't *need* at all to find any particular combination of values, because as other members of the community pointed out, both Gtk and Qt apps are perfectly able to find their way to their preferred display client. So the best course of action is simply to not force any particular value down their throat, which as far as I know boils down to simply removing the xwayland and wayland ("Full wayland") sessions, replacing them with a session in line with upstream, which does not bake these values into their plasma desktop builds.
To me the situation can be summarized by: we're altering the plasma desktop from upstream, sending to library and application developers a message that is more or less "we don't care what you guys think your programs should display to, because we at oS know better". This message would be tolerable if it secured the best for our users, but as I've tried to suggest, that's not the case. Not only are our users going to have a flawed perception of the Plasma desktop, because it behaves too rogue to express the intent of upstream, but we are making it unnecessarily difficult for our users to get decent troubleshooting, because no other distribution does it our way. That means a much smaller user pool to draw from when troubleshooting our users, and requires that our users remember to warn people at bugs triage that they're using a *special plasma config*.
I've reached out yesterday to Fabian Vogt -- one of the maintainers of our plasma desktop package -- on these matters, and so far he has been helpful and open-minded. I certainly don't want to arm-wrestle him over this mailing list. Instead I am trying to fulfill his demand for more user feedback.
The right way to do that is by asking in an "unbiased" mail, because only then replies can be based on an informed decision. This mail doesn't fit that criteria unfortunately. It also omits the reasons why this split between the two Wayland session types was introduced in the first place.
Cheers, Fabian
Best,
Adrien
Hi, Am Dienstag, 9. März 2021, 11:17:31 CET schrieb Adrien Glauser:
Oups pressed the wrong button and the first part of my reply to Fabian was not CC'ed to the list:
8<--------------------------
Dear Fabian,
Thanks for your email, I appreciate.
I've checked out the thread you mention as a poll. I see only 1 reply there. Where can I see the other replies -- if possible those that specifically address the question, because you're asking two separate questions in that poll?
IIRC there were just three or so replies in total, none of which were against the "Xwayland" session. There weren't any bug reports about this either, and IIRC there still aren't. As a conclusion, the status quo was kept.
Who are the "testers" you refer me to? (Sorry I've been a member of oS since last summer, and I don't know who they are).
In that case I just meant anyone who does testing for this topic. What needs to be tested is whether the issues the "Xwayland" session works around are still present and to which extent. The easiest way to do that is by using the "Full Wayland" session instead. So everyone using "Plasma (Wayland)" should try "Plasma (Full Wayland)" and report issues.
And again, isn't asking for their feedback replaying the same issue (i.e. bias control) in a different context?
There's always bias to some extent, but there's a world of difference between "X is great" and "Please try out Y", if the goal is to collect plain data.
Finally did you apply the same measures for extracting unbiased feedback when you or your predecessor introduced this patching?
It was never actively introduced, it was the upstream default in Qt until 5.9 (IIRC). When Qt 5.9 with the change arrived in TW, there were some bug reports and mails about this, so we simply decided to revert the change and keep the old default for longer. Cheers, Fabian
Cheers,
Adrien
Le 09/03/2021 à 10:35, Fabian Vogt a écrit :
Hi,
there are some misunderstandings and misconceptions in this mail and the replies. I don't have the time to clear those up in depth right now, so I hope that there's enough info in this thread: https://lists.opensuse.org/archives/list/kde@lists.opensuse.org/message/BIWK... It's a link to a poll on this topic from half a year ago on [os-kde], where I also explained the background.
tl;dr: It exists for an easier transition to using Plasma with Wayland, to work around certain shortcomings (middle-click paste, application interop) and bugs (KMail/WebEngine on Wayland. If those shortcomings are no longer there or no longer relevant to the target group (recent/current users of the X11 sessions), then the deviation from upstream defaults served their purpose and can be retired.
Input from users is needed for that, to ensure that it doesn't introduce any regressions which force them away from the Wayland sessions again.
The alternative is to do a scream test: Switch the defaults and see whether someone complains.
I'm not opposed to either of those and would prefer a combination: Ask for feedback from testers, and if it's not enough, do the scream test. I'm more than happy to drop this, if it's the right time.
Am Montag, 8. März 2021, 11:08:59 CET schrieb Adrien Glauser:
Dear all,
Over the past months I've run into multiple bugs on both "wayland sessions" shipped by default by Tumbleweed (Leap uses the same settings so it's in the same boat as far as I can tell) which I was never running into on two other Linux distributions (i.e. NixOS and Fedora). This caught my attention and after back and forth discussions with Plasma developers and members of the oS community, this conclusion has become inescapable: most of these bugs are not just facilitated, but outright *caused* by certain settings that the package maintainer(s) of the Plasma desktop have decided to apply, against the recommendations of the Plasma developers.
It has to be noted that "package maintainers" and "Plasma developers" are not two disjoined groups.
The Qt Wayland QPA has known issues, and it actually disables itself by default in a GNOME session for those reasons and uses xcb instead.
If like me a couple of days ago you aren't familiar with this topic, the issue revolves around two environmental variables which our Plasma packagers have decided to override: - GDK_BACKEND: our xwayland session (displayed as "Plasma Wayland" in SDDM) is built with a patch overriding its value to "xcb", while our wayland session (displayed as "Plasma Full Wayland in SDDM) overrides it to "wayland" - QT_QPA_PLATFORM: overriden to "xcb;wayland" and "wayland;xcb" in the two sessions respectively.
The "Plasma (Wayland)" session does not override QT_QPA_PLATFORM.
Both variables are read at runtime to control the choice of a display client by GTK and Qt apps, as their name suggests. In this instance our xwayland session forces GTK apps to use an X11 client, whereas our wayland ("Full Wayland") session forces them to use a Wayland client. As for Qt apps, xwayland forces them to use an X11 client -- with a fallback on a wayland client -- while wayland ("Full Wayland") does things vice-versa -- forces them to use a wayland client, with a fallback on X11.
Now for the issue: roughly put, the issue is that the decision to override these values corners users in an impossible dilemma. To appreciate the dilemma, we can consider two widely used sets of applications: a. recent, well-maintained Qt/GKT native applications installed from official .RPM packages (typically: Kate, Konsole, Kwin); and b. flatpak-ed, apps using either slightly outdated GTK libraries or based on the Electron stack (~ most of the flatpaks)
If the user picks xwayland, several apps in (a) will run into issues. The reason is that KDE developers, in the course of migrating their code base to the wayland compositing protocol, have made substantial efforts to make these applications play nice with a wayland client, and pushing these applications in the reverse direction is likely to introduce regressions, to escape test coverage and make it very, very difficult for the end user to get troubleshooting and support from KDE. While if the user picks wayland ("Full Wayland"), the (a)-applications will run fine but the (b)-applications will be very buggy, and most of them will just refuse to launch.
And by the way it's very easy for you to test both horns of the dilemma. That's simply a cherry-picked example, but it's not difficult to come up with more: try making a custom, rectangular capture using Spectacle in xwayland (this will fail because the program was built with the idea that it would output to wayland, not X11); or try launching something like the OBS Studio flatpak in wayland ("Full Wayland").
Until yesterday I thought that the solution to this pain was to use a different choice of values for GDK_BACKEND and QT_QPA_PLATFORM, setting them for example to "xcb" and "wayland;xcb", building on the assumption that Qt apps need wayland and that Gtk apps are compatible with X11. But in fact we don't *need* at all to find any particular combination of values, because as other members of the community pointed out, both Gtk and Qt apps are perfectly able to find their way to their preferred display client. So the best course of action is simply to not force any particular value down their throat, which as far as I know boils down to simply removing the xwayland and wayland ("Full wayland") sessions, replacing them with a session in line with upstream, which does not bake these values into their plasma desktop builds.
To me the situation can be summarized by: we're altering the plasma desktop from upstream, sending to library and application developers a message that is more or less "we don't care what you guys think your programs should display to, because we at oS know better". This message would be tolerable if it secured the best for our users, but as I've tried to suggest, that's not the case. Not only are our users going to have a flawed perception of the Plasma desktop, because it behaves too rogue to express the intent of upstream, but we are making it unnecessarily difficult for our users to get decent troubleshooting, because no other distribution does it our way. That means a much smaller user pool to draw from when troubleshooting our users, and requires that our users remember to warn people at bugs triage that they're using a *special plasma config*.
I've reached out yesterday to Fabian Vogt -- one of the maintainers of our plasma desktop package -- on these matters, and so far he has been helpful and open-minded. I certainly don't want to arm-wrestle him over this mailing list. Instead I am trying to fulfill his demand for more user feedback.
The right way to do that is by asking in an "unbiased" mail, because only then replies can be based on an informed decision. This mail doesn't fit that criteria unfortunately. It also omits the reasons why this split between the two Wayland session types was introduced in the first place.
Cheers, Fabian
Best,
Adrien
Fabian, your package diverge from the "pure, unpatched, not reconfigured" plasma-workspace produced upstream. *That* upstream package is our test target, to justify the extent to which we need to diverge: - if the upstream package is satisfying to the user, it should be the one shipped to oS distros; and - if it's not, you'll be able to extrapolate from the feedback we'll get you whether GDK_BACKEND & QT_QPA_PLATFORM should be set to some value (as opposed to left alone), and also which specific value to set them to (if at all). Also Fabian, would be willing to create this package on Factory, while we announce a time window for the community to try it, with guidelines as to how participate to the test? If so, I'd be happy to take care of the announcement post on news-o-o, if you can make the test build. Then I'd send you my text so that you can check it out for bias risks, and after your validation I'd post it to news-o-o. Does that look like a fair deal for you?
Hi, Am Dienstag, 9. März 2021, 16:47:24 CET schrieb Adrien Glauser:
Fabian, your package
Why are you trying to make this a personal issue now?
diverge from the "pure, unpatched, not reconfigured" plasma-workspace produced upstream. *That* upstream package is our test target, to justify the extent to which we need to diverge:
Honestly, the tone of that statement doesn't sit well with me.
- if the upstream package is satisfying to the user, it should be the one shipped to oS distros; and - if it's not, you'll be able to extrapolate from the feedback we'll get you whether GDK_BACKEND & QT_QPA_PLATFORM should be set to some value (as opposed to left alone), and also which specific value to set them to (if at all).
Top priority (at least for me) is user experience. It's what finally counts.
Also Fabian, would be willing to create this package on Factory, while we announce a time window for the community to try it, with guidelines as to how participate to the test?
I already proposed a way how to do the relevant tests easily, without any package changes on the system. So far you dismissed that and also the reasons the split sessions exist in the first place. That way there's no common ground, which is key to a proper discussion. Here's an untested (!) project with just a single "Plasma (Wayland)" session: https://build.opensuse.org/project/show/home:Vogtinator:lessxwl After adding, install with "zypper dup --from lessxwl --allow-vendor-change". Might need Plasma 5.21.2, which TW so far couldn't pick up. I have to repeat that this is not the method for testing I recommend.
If so, I'd be happy to take care of the announcement post on news-o-o, if you can make the test build. Then I'd send you my text so that you can check it out for bias risks, and after your validation I'd post it to news-o-o.
Does that look like a fair deal for you?
AFAICT, we're on the same side, we just differ in the view on how to approach this. That really has to be cleared up first. Please also look at the side of the discussion which isn't yours. Cheers, Fabian
Op 09-03-2021 om 21:25 schreef Fabian Vogt:
Hi,
Am Dienstag, 9. März 2021, 16:47:24 CET schrieb Adrien Glauser:
Fabian, your package
Why are you trying to make this a personal issue now?
diverge from the "pure, unpatched, not reconfigured" plasma-workspace produced upstream. *That* upstream package is our test target, to justify the extent to which we need to diverge:
Honestly, the tone of that statement doesn't sit well with me.
- if the upstream package is satisfying to the user, it should be the one shipped to oS distros; and - if it's not, you'll be able to extrapolate from the feedback we'll get you whether GDK_BACKEND & QT_QPA_PLATFORM should be set to some value (as opposed to left alone), and also which specific value to set them to (if at all).
Top priority (at least for me) is user experience. It's what finally counts.
Also Fabian, would be willing to create this package on Factory, while we announce a time window for the community to try it, with guidelines as to how participate to the test?
I already proposed a way how to do the relevant tests easily, without any package changes on the system. So far you dismissed that and also the reasons the split sessions exist in the first place. That way there's no common ground, which is key to a proper discussion.
Here's an untested (!) project with just a single "Plasma (Wayland)" session: https://build.opensuse.org/project/show/home:Vogtinator:lessxwl After adding, install with "zypper dup --from lessxwl --allow-vendor-change". Might need Plasma 5.21.2, which TW so far couldn't pick up. I have to repeat that this is not the method for testing I recommend.
If so, I'd be happy to take care of the announcement post on news-o-o, if you can make the test build. Then I'd send you my text so that you can check it out for bias risks, and after your validation I'd post it to news-o-o.
Does that look like a fair deal for you?
AFAICT, we're on the same side, we just differ in the view on how to approach this. That really has to be cleared up first. Please also look at the side of the discussion which isn't yours.
Cheers, Fabian
If I understand correctly the two options of "Plasma Wayland" and "Plasma Full Wayland" are an all or nothing approach: at login the default is set for all applications. I can see this is good for testing, but in normal use it gives problems. At least, as far as I can see. An application like zotero (for working with bibliographies, www.zotero.org) does not have wayland support. In Full Wayland it does not start. It took me some time to find the workaround, setting GDK_BACKEND=x11 explicitly before executing this app. I did a test and removed GDK_BACKEND=wayland from plasmafullwayland in /usr/share/wayland-sessions. I don't know what this means and what is set for GDK_BACKEND in that case, but I saw that firefox worked better than with the old GDK_BACKEND=wayland setting. Because of bug [1] firefox is unusable in full wayland, but starting the the changed plasmafullwayland the bug is not there. Maybe it is because x11 is used, but looking at /usr/lib64/firefox/firefox.sh it tests for a wayland session. I don't know how useful this observation is, I am far from an expert and find it all a bit confusing, but who knows. :) Regards, Cor [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1660567
Definitions: - upstream plasma-workspace, "UPW": https://invent.kde.org/plasma/plasma-workspace - upstream default plasma-workspace session, "UDS": UPWs' default session - oS plasma-workspace, "osPW": https://build.opensuse.org/package/show/KDE:Unstable:Frameworks/plasma5-work... - oS plasma-workspace Full Wayland session, "Full Wayland": one of the two osPW sessions - the GDK_BACKEND patch, "The Patch", https://build.opensuse.org/package/view_file/KDE:Unstable:Frameworks/plasma5...) - "Unpatched": Full Wayland minus The Patch Assumptions: 0. Unpatched is relevantly identical to UDS, that is, as far as the values of QT_QTA_PLATFORM & GDK_BACKEND are concerned 1. As far as user experience (including stability for both GTK & Qt applications), sustainability in view of upstream support, and performances: Unpatched > Full Wayland > Xwayland > X Question: - Would the osPW packagers & maintainers be so kind as to make and provide a package offering Unpatched for the openSUSE community to test out, so as to adduce evidence for or against (1)? If the answer to the question is 'Yes', I would be happy to collaborate closely with the osPW packagers & maintainers to ensure that the appropriate communication is done, so as to minimize bias risks and to make sure that consent or dissent are well-informed.
Dear Adrien, there are two issues with your argument. 1 you assume there is a plasma upstream, in my opinion that stopped to be the case when kde neon was created. so just copying the "upstream settings" will not solve the issue.I know there are plenty of people who will disagree. but at the end I can see the broken eggs but I fail to see the omlette. the other issue does not matter how you will set the backend the applications will not look good. there is no amount of lipstick you can put on a pig to make it a unicorn. provide patches and bug reports but do not expect miracles. I have spent part of the morning testing the full wayland session coming from the scenario of a working machine properly setup kde x11. Experience was atrocious and that had nothing to do with packaging. (apps crashing, session not cleaned properly, unable to change resolution, ugly applications and some of them I know are upstream things, others which were new things, Fabian found out were upstream too). unfortunately time does not allow me to setup my machine with fedora and use it for few weeks to see what is the situation in there. In the past when I did this experiment the situation was the same. of course you can argue ad infinitum that my experience is not other users experience, cause I may need to start with a clean user, stand on one foot and have my hands in pocket. Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Wed, 10 Mar 2021 at 07:52, Adrien Glauser <adrien.glauser@gmail.com> wrote:
Definitions: - upstream plasma-workspace, "UPW": https://invent.kde.org/plasma/plasma-workspace - upstream default plasma-workspace session, "UDS": UPWs' default session - oS plasma-workspace, "osPW": https://build.opensuse.org/package/show/KDE:Unstable:Frameworks/plasma5-work... - oS plasma-workspace Full Wayland session, "Full Wayland": one of the two osPW sessions - the GDK_BACKEND patch, "The Patch", https://build.opensuse.org/package/view_file/KDE:Unstable:Frameworks/plasma5...) - "Unpatched": Full Wayland minus The Patch
Assumptions: 0. Unpatched is relevantly identical to UDS, that is, as far as the values of QT_QTA_PLATFORM & GDK_BACKEND are concerned 1. As far as user experience (including stability for both GTK & Qt applications), sustainability in view of upstream support, and performances: Unpatched > Full Wayland > Xwayland > X
Question: - Would the osPW packagers & maintainers be so kind as to make and provide a package offering Unpatched for the openSUSE community to test out, so as to adduce evidence for or against (1)?
If the answer to the question is 'Yes', I would be happy to collaborate closely with the osPW packagers & maintainers to ensure that the appropriate communication is done, so as to minimize bias risks and to make sure that consent or dissent are well-informed.
There is no plasma upstream
"there is no amount of lipstick you can put on a pig to make it a unicorn"
My argument is that the community deserves to be able to test it and come to a verdict. If you're interested in a release of plasma that is closer to upstream with respect to the two environment variables at the center of my argument, you can look at what Fedora does: https://koji.fedoraproject.org/koji/rpminfo?rpmID=25429428
On 3/10/2021 0:52, Adrien Glauser wrote:
... - the GDK_BACKEND patch, "The Patch", https://build.opensuse.org/package/view_file/KDE:Unstable:Frameworks/plasma5...) - "Unpatched": Full Wayland minus The Patch ...
Question: - Would the osPW packagers & maintainers be so kind as to make and provide a package offering Unpatched for the openSUSE community to test out, so as to adduce evidence for or against (1)?
1. As far as user experience (including stability for both GTK & Qt applications), sustainability in view of upstream support, and
It's a single environment variable, can't you just "unset" it if you want to test what it's like without it? Furthermore, you've gone to all the trouble of finding the patch you deem so offensive, what's stopping you from branching the package, removing the patch and then you've got what you are asking for? I would, however, probably use "KDE:Frameworks5/plasma5-workspace" rather than "KDE:Unstable:Frameworks" if you want it to be more analogous to what is currently in Tumbleweed. performances: Unpatched > Full Wayland > Xwayland > X I would say it is rather more correct that X has the best user experience at the moment. That may change in the future but only if people actually try out Wayland in its various forms and SUBMIT BUGS to appropriate entities when they encounter problems. There are still a lot of problems on both the DE and application side of the Wayland equation to be considering it a better user experience than X. You yourself have been stating some of them. -- Jason Craig
Me testing is not really relevant. What's relevant is collecting a statistically significant amount of data, which Fabian has been asking himself, and in that regard I am in complete agreement with him. Also, it would take the plasma-workspace maintainers considerably less effort to spin a test package free of this patch than it would take me to start from scratch. I am far from the oS packager black-belt, to be honest, and my plate is really full with oS things already. I just cannot be everywhere. That said, if someone else wants to spin that test package, it would also satisfy me, and probably many people who've weighed in favourably to my request in this topic. I can't help but find it more natural that the same folks who claim this patch is required agree to justify their claim by providing the community a way of testing, but in the end, only the result matters.
In data martedì 9 marzo 2021 16:47:24 CET, Adrien Glauser ha scritto:
Fabian, your package diverge from the "pure, unpatched, not reconfigured" plasma-workspace produced upstream. *That* upstream package is our test
"Your"? Packages in the KDE repositories are maintained collectively: by Fabian, Christophe, me, and Antonio. But also anyone is welcome to contribute. You make it sound like a decision made on a whim: it was instead done collegially, so to speak. And it's not the only package where we have different defaults from upstream. Doing things different from upstream per se is neither a good nor a bad point, and is precisely what an integrator (such as openSUSE) can do. -- Luca Beltrame GPG key ID: A29D259B
Well, when I am in my sailboat coming across another sailboat, and I get to address one sailor in particular in the other sailboat, saying "<proper name>, your sailboat is sailing West", that is usually not interpreted as in a way that contradicts the proposition that the other sailboat is being managed and steered collectively. It is in fact compatible with that proposition, and with any proposition about the relationship between the addressed sailor and the rest of the crew. There is no need for interpreting my sentence otherwise :)
Am 09.03.21 um 10:35 schrieb Fabian Vogt:
Input from users is needed for that, to ensure that it doesn't introduce any regressions which force them away from the Wayland sessions again.
The alternative is to do a scream test: Switch the defaults and see whether someone complains.
I'm not opposed to either of those and would prefer a combination: Ask for feedback from testers, and if it's not enough, do the scream test. I'm more than happy to drop this, if it's the right time.
Why not introduce a third session type that goes with the upstream defaults? Then those who want can try it out without interfering with those that are happy with the existing session types, or prefer a more conservative or experimental KDE desktop. Eventually the community might converge on a session type, but currently things are still in flux and I guess it's hard to say which approach is the best. Best regards, Aaron
Aaron Puchert skreiv 09.03.2021 23:23:
Why not introduce a third session type that goes with the upstream defaults? Then those who want can try it out without interfering with those that are happy with the existing session types, or prefer a more conservative or experimental KDE desktop.
+1 Having an easy way to choose been all three session makes testing much faster and easier. I’ll be willing to test all three and provide feedback. -- Karl Ove Hufthammer
Been taking a look at this thing for a while. To be honest, I sense the current situation is about lack of communication. Every once in a while I see people complain about things not working on Wayland or how is KDE on Wayland doing right now (usually on Telegram or Discord). Trying to think as an end user just hopping into openSUSE distros and see things not working 'as usual' on Wayland may be confusing. There is no clear indication of what is going on behind the scenes, aside from the session names, but that doesn't really tell the whole story. The thing that bugs me is that, in the end, "this" patch gets in the way of troubleshooting. Users willing to do bug reporting on the topic of KDE/Wayland have higher chances of getting with a WONTFIX or something alike, simply because of downstream behavior. I don't think "the patch" affects mildly experienced users that much, but I sure am on the side of seeing this fade away eventually. Were this patch to be removed soon, I think it would be important to let packagers know ahead of time so they can check if their projects need patching or special tweaks. What about a two month deadline for this? I'm just trying to find the gray area, since I think we can all agree on this here: Plasma on Wayland is getting good, but is no there quite yet. For reference: my experience is the same as Attila and Knurpht. The moment I discovered that patch it was an "aha! moment", this explains why some flatpaks were not working on Wayland (they had fallback to X11 and Wayland access enabled) or why some GTK apps were looking blurry. My solution: I'll just fork plasma-workspace and disable the patch for me. I like Fabian's proposal: Quoting: ---begin quote--- tl;dr: It exists for an easier transition to using Plasma with Wayland, to work around certain shortcomings (middle-click paste, application interop) and bugs (KMail/WebEngine on Wayland. If those shortcomings are no longer there or no longer relevant to the target group (recent/current users of the X11 sessions), then the deviation from upstream defaults served their purpose and can be retired. Input from users is needed for that, to ensure that it doesn't introduce any regressions which force them away from the Wayland sessions again. ---end quote--- This proposal also fulfills my idea of having better communication about the issue. On the topic of asking about feedback, what would the process of testing look like? Just add a repo, zypper dup --allow-vendor-change and good to go? I mean, if users are expected to run some kind of tests or just use the session as they would normally. Saludos.
These have been my findings on these two days of using the "unpatched" session: - QT_QPA_PLATFORM defaults to xcb but the Plasma session itself is running on Wayland, this can be verified via system settings. XDG_SESSION_TYPE is wayland. When checked through qtdiag on Konsole, it reports xcb. - Spectacle's rectangular selection does not work on xcb, so out of the box this can cause annoyances. If forced to wayland, it works fine but Spectacle itself appears on the screenshot or in the middle of the fading out animation. - Discord, Element, Firefox (with MOZ_ENABLE_WAYLAND=1), Signal, PLECS, MATLAB, Codium, GIMP, KiCad, LibreOffice, Inkscape and Kdenlive seemed to work with no problems on the "upstream" session. All the electron apps in the list are running on flatpak except Codium. - As usual, the NVIDIA GPU (Optimus) feature of PRIME render offload did not work on Wayland, nevermind launching a full session. - Kdenlive crashes if forced to Wayland, but it does work under xcb. Error info on Wayland seems to not help much by itself: QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x562426067b00 QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x5624272cc5d0 QWaylandGLContext::makeCurrent: eglError: 3009, this: 0x7faf18009410 QOpenGLFunctions created with non-current context Under xcb it detects NVENC, as expected. Can't tell for Wayland since it was crashing, but in theory it should. - On either session, I could not type "tildes" (spanish accent mark) on Telegram - Flatpak. No idea why this would happen, but this was not an issue on Firefox, seééééééé thís. - On LibreOffice, the tilde was not working for QT...=wayland, but on xcb it did. - I set my default session to Plasma (Wayland) and almost forgot I had it that way; aside from the Spectacle issue and the inherent smoothness to using Wayland, I could not notice an important difference from the XOrg session, which from my point of view is good news for Plasma in general. - Right click menu on Full Wayland seemed to be unrealiable: sometimes it would ignore my left click when selecting an option. - Sometimes it would be obvious when something was running on XWayland because the application would launch into a blackscreen during the fraction of a second. - On QT...=wayland Plasma would misplace prompts (e.g. Gparted asking for permission) at the top left corner, while if QT... is not forced by me this would not happen. I think a good approach would be to keep Full Wayland as is and have a Wayland session without "the patch" (not force any variables in that one). This option would also allow users with the appropriate knowledge to create their own .desktop sessions and fine tune their experience, but they can already sort of do that. The key difference is that they can force GDK_BACKEND if preferred, but only if they want to. If some help is needed to test something, let me know. * That is, once my ISP gets his .... right and I can do the 5.85 GB update that just dropped on my main laptop :D
Done a less data- and more user focused experiment by installing KDE Neon on an empty box of mine. Specs: ``` KDE Plasma Version: 5.21.2 KDE framework version: 5.79.0 QT version: 5.12.2 Kernel version: 5.4.0-66-generic OS Type: 64-bit Graphics platform: Wayland Processor: 4x AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6GG Memory 10.7 GiB of RAM Graphics Processor: AMD KAVERI ``` Output of `qtdiag`: https://paste.opensuse.org/86576221 Output of `/usr/share/wayland-sessions/plasmawayland.desktop`: https://paste.opensuse.org/29250059 Copy pasting works fine between kwin > VSCode flatpak; VSCode flatpak > kwin; VSCode flatpak > konsole; konsole > VSCode flatpak Flatpaks are fine, native GTK applications fine, Electron applications are fine. The following has been tested: Element (deb), Firefox(deb), Telegram(snap), MS Edge (deb), Zoom (deb), Chrome (deb), Chromium (deb), VSCode (deb and flatpak) and Spectacle works fine. I had an issue with Discord snap which I switched to the flatpak and worked fine. On the request of Adrien I also tried to create a pgp encrypted e-mail, using Evolution and it worked fine as well. There was another request for testing scaling of PyCharm and Idea, also worked fine. There was also a theme change test I've tried. Downloading the Guvbox theme from the System Settings, apply it and on openSUSE Plasma XWayland for the first time it crashed so hard I had to reboot the machine. On Neon it didn't crash, but I was able to get it to by switching between Gruvbox and Breeze Dark 2-3 times. However, on Neon the desktop recovered without me doing anything. My experience. The box is alive, if anybody wants me to test anything just throw instructions on me.
After testing the lessxwl and differentxwl repos, I think the best approach is lessxwl, especially because Firefox prefers Wayland on that configuration. Both repos were tested for about a week, and I think I'll go back X.Org for now. Telegram (Flatpak) and Firefox crash at least once every two hours, and the fact that spanish accent marks are not working on Qt apps (that includes LibreOffice for some reason, probably because the Qt version is the one shipped with Plasma). Minecraft worked fine with the Intel GPU, and NVIDIA, of course was NVIDIA, as usual, no need for details. * Minecraft works over XWayland Either repo was clearly a better alternative than the current implementation. Also, the rectangular selection issue with Spectacle has been fixed with the version 20.12.3. Vivaldi also worked fine on the lessxwl repo, and definitely crashed less than Firefox. (and no, I won't try Edge :p) The change to either repo was seamless for me; in my opinion we can for the scream test.
PD1: yes, Plasma crashes at least twice a day, same as Neon, it recovers itself, most of the time. One issue I had a few times was that clicking my open programs in the taskbar opened new instances, despite me not having any pinned programs. PD2: I launch with with this MOZ_ENABLE_WAYLAND=1 firefox and have some tweaks in about:config that may indeed affect the stability of it, so this could be my fault :D Can't speak for Telegram, maybe it's something in the Flatpak using old stuff, I don't know.
Hi, Am Mittwoch, 31. März 2021, 23:24:59 CEST schrieb Andrés Barrantes Silman:
After testing the lessxwl and differentxwl repos, I think the best approach is lessxwl, especially because Firefox prefers Wayland on that configuration.
That is strange, because the "Full Wayland" session for both is identical (or at least supposed to be). The only difference is that "differentxwl" still offers the "XWayland" session, but by patching Qt (which isn't great).
Both repos were tested for about a week, and I think I'll go back X.Org for now. Telegram (Flatpak) and Firefox crash at least once every two hours,
Do you have a link to the upstream reports or have a backtrace? Do the crashes disappear when you run them with Xwayland? If so, then they are one of the reasons why it's IMO beneficial to have a simple option available which makes those applications use Xwayland. Doing that for the whole session (like it is currently) is indeed not ideal.
and the fact that spanish accent marks are not working on Qt apps (that includes LibreOffice for some reason, probably because the Qt version is the one shipped with Plasma).
Is this using the compose key or just plain dead keys as part of the keyboard layout?
Minecraft worked fine with the Intel GPU, and NVIDIA, of course was NVIDIA, as usual, no need for details. * Minecraft works over XWayland
Either repo was clearly a better alternative than the current implementation.
What made the biggest difference?
Also, the rectangular selection issue with Spectacle has been fixed with the version 20.12.3.
Vivaldi also worked fine on the lessxwl repo, and definitely crashed less than Firefox. (and no, I won't try Edge :p)
The change to either repo was seamless for me; in my opinion we can for the scream test.
Ok, so I propose this: Unless there's an objection in the next few days, we'll send an announcement about this change to the MLs (os-f, os-kde) and ask about any regressions in application behaviour or reliability. When the announcement is out, change the default in qtbase to "wayland;xcb" and drop the "XWayland" session. Based on the (hopefully extensive) feedback on applications, further changes can be discussed, maybe application-specific changes. Cheers, Fabian
That is strange, because the "Full Wayland" session for both is identical (or at least supposed to be). The only difference is that "differentxwl" still offers the "XWayland" session, but by patching Qt (which isn't great).
Apparently it had to do with how the enviroment variables were ordered: if GDK_BACKEND was set to "x11,wayland" it preferred x11, but if it was "wayland ,x11" it went for wayland.
Do you have a link to the upstream reports or have a backtrace?
No, sorry. I could try to troubleshoot a little bit but lack time right now.
Is this using the compose key or just plain dead keys as part of the keyboard layout?
Compose key - this was fixed recently: https://bugs.kde.org/show_bug.cgi?id=411729 https://bugreports.qt.io/browse/QTBUG-87088
What made the biggest difference?
For me, the fact that Vivaldi, VS Codium and Element were working without touching enviroment variables.
change the default in qtbase to "wayland;xcb" and drop the "XWayland" session
In the case of GDK_BACKEND, what would happen?
Hi, Am Sonntag, 9. Mai 2021, 22:59:35 CEST schrieb Andrés Barrantes Silman:
That is strange, because the "Full Wayland" session for both is identical (or at least supposed to be). The only difference is that "differentxwl" still offers the "XWayland" session, but by patching Qt (which isn't great).
Apparently it had to do with how the enviroment variables were ordered: if GDK_BACKEND was set to "x11,wayland" it preferred x11, but if it was "wayland ,x11" it went for wayland.
Do you have a link to the upstream reports or have a backtrace?
No, sorry. I could try to troubleshoot a little bit but lack time right now.
Is this using the compose key or just plain dead keys as part of the keyboard layout?
Compose key - this was fixed recently: https://bugs.kde.org/show_bug.cgi?id=411729 https://bugreports.qt.io/browse/QTBUG-87088
Apparently qtwayland had compose key support for a while and it was removed again, but now reintroduced... I submitted qtwayland with the latest changes from the kde patch collection, which includes this fix.
What made the biggest difference?
For me, the fact that Vivaldi, VS Codium and Element were working without touching enviroment variables.
Ah, so probably GDK_BACKEND=wayland.
change the default in qtbase to "wayland;xcb" and drop the "XWayland" session
In the case of GDK_BACKEND, what would happen?
If the concept of having separate sessions for "app compatibility" and "wayland features" is dropped, then setting QT_QPA_PLATFORM and GDK_BACKEND has to be dropped as well. Now with Plasma 5.22 around the corner and the Beta already in KDE:Frameworks5, I'm wondering about the timing of this change. While it might make sense to do this together with the 5.22 update, IMO it's also not great to have too many changes at once. Should this be postponed to around ~5.22.1 time? The TW submission process doesn't easily allow testing 5.22 in parallel with submitting the change to plasma5-workspace-5.21.5. Cheers, Fabian
I'm wondering about the timing of this change. While it might make sense to do this together with the 5.22 update, IMO it's also not great to have too many changes at once.
To be honest, I was thinking the same. No problem for me if we can delay it a little bit.
If the concept of having separate sessions for "app compatibility" and "wayland features" is dropped, then setting QT_QPA_PLATFORM and GDK_BACKEND has to be dropped as well.
Just to be clear, so the consensus is to keep the "Full Wayland" session as-is (included by default or not?) and make the "Wayland" session vanilla?
Hi, Am Sonntag, 16. Mai 2021, 21:36:51 CEST schrieb Andrés Barrantes Silman:
I'm wondering about the timing of this change. While it might make sense to do this together with the 5.22 update, IMO it's also not great to have too many changes at once.
To be honest, I was thinking the same. No problem for me if we can delay it a little bit.
If the concept of having separate sessions for "app compatibility" and "wayland features" is dropped, then setting QT_QPA_PLATFORM and GDK_BACKEND has to be dropped as well.
Just to be clear, so the consensus is to keep the "Full Wayland" session as-is (included by default or not?) and make the "Wayland" session vanilla?
The "XWayland" session with its goal of being more compatible with applications designed for X11 has the downside of not allowing certain Wayland features to work, so the "Full Wayland" session was introduced to counteract that by restoring the Wayland default for GTK and Qt applications, i.e. being the vanilla Wayland session again. When the "Wayland" session no longer defaults applications to use X11, then there's no difference to "Full Wayland" anymore. Though if it turns out that we have to make some applications (like KMail) default to X11 again, we might also need some switch to turn that back off. This could be done using a different kind of "Full Wayland" session then. Cheers, Fabian
Ok! For now I'll revoke the merge request, see how Wayland works on the 5.22 release and test my changes there again. I expect this to become less of an issue eventually, now that Electron has better support for Wayland (as for Discord, eventually means centuries later) and PipeWire keeps getting better.
App compatibility being better served by dropping setting QT_QPA_PLATFORM and GDK_BACKEND, indeed.
Dear everybody involved As the Plasma 5.22.1 is upon us I would like to ask to ask if there is any consensus on removing/changing the discussed "patch"? I have switched to the lessxwl repo after Plasma 5.22 arrived and so far it has been very smooth experience (many thanks to Fabian for maintaining it) Personally I would support dropping the patch (if I understand correctly that this is what the lessxwl-plasma does) From my rather shallow user perspective I see this advantages in the unpatched wayland session: - lots of stuff runs on wayland which is fast smooth, more secure etcetc (way more than on the "xwayland session" I think) - apps that don't support wayland run happily under xwayland without me interfering (i.e. teams, mailspring - they would not run without me manually setting the env variables) All the best Ondrej
On 16. 06. 21, 22:48, Ondřej Růžička wrote:
Dear everybody involved As the Plasma 5.22.1 is upon us I would like to ask to ask if there is any consensus on removing/changing the discussed "patch"?
What is "the patch" after all? Do you have a link? I've switched to wayland this week. And "full wayland" does not work for me (thunderbird flickers all the time, middle mouse button defunct, etc.). So I would like to see what we actually patch... regards, -- js suse labs
On Wed, Jun 23, 2021 at 4:18 AM Adrien Glauser <adrien.glauser@gmail.com> wrote:
"the patch" => https://build.opensuse.org/package/view_file/openSUSE:Factory/plasma5-worksp...
The specifics of what breaks things is the following (as of the commit 3 days ago): * Patch: https://code.opensuse.org/package/plasma5-workspace/blob/8912e3a7f032438b75e... * Spec stuff: https://code.opensuse.org/package/plasma5-workspace/blob/8912e3a7f032438b75e... These changes are what create the confusing setup for Plasma Wayland in openSUSE. -- 真実はいつも一つ！/ Always, there's only one truth!
Hi all, I use Tumbleweed + full Wayland KDE. The mail accounts are disconnected in kmail and they do not connect. I get this message in terminal : kmail No text-to-speech plug-ins were found. Running on wayland. Qt WebEngine will disable usage of the GPU. Note: you can set the QT_WEBENGINE_DISABLE_WAYLAND_WORKAROUND environment variable before running this application, but this is not recommended since this usually causes applications to crash. Cannot initialize model with data QJsonObject() . missing: QJsonValue(string, "urls") qt.qpa.wayland: Wayland does not support QWindow::requestActivate() kf.xmlgui: Index 23 is not within range (0 - 21 ) kf.xmlgui: Index 25 is not within range (0 - 21 ) I don't known why this issue with plasma full Wayland. It works on x11. Can you tell me if the patches discussed here are to blame or do I have to file a bug report? Thank you
Op 24-06-2021 om 10:24 schreef Lucie Charrier:
Hi all, I use Tumbleweed + full Wayland KDE. The mail accounts are disconnected in kmail and they do not connect. I get this message in terminal : kmail No text-to-speech plug-ins were found. Running on wayland. Qt WebEngine will disable usage of the GPU. Note: you can set the QT_WEBENGINE_DISABLE_WAYLAND_WORKAROUND environment variable before running this application, but this is not recommended since this usually causes applications to crash. Cannot initialize model with data QJsonObject() . missing: QJsonValue(string, "urls") qt.qpa.wayland: Wayland does not support QWindow::requestActivate() kf.xmlgui: Index 23 is not within range (0 - 21 ) kf.xmlgui: Index 25 is not within range (0 - 21 )
I don't known why this issue with plasma full Wayland. It works on x11. Can you tell me if the patches discussed here are to blame or do I have to file a bug report? Thank you
Am Donnerstag, 17. Juni 2021, 08:17:20 CEST schrieb Jiri Slaby:
On 16. 06. 21, 22:48, Ondřej Růžička wrote:
Dear everybody involved As the Plasma 5.22.1 is upon us I would like to ask to ask if there is any consensus on removing/changing the discussed "patch"?
What is "the patch" after all? Do you have a link?
I've switched to wayland this week. And "full wayland" does not work for me (thunderbird flickers all the time, middle mouse button defunct, etc.). So I would like to see what we actually patch...
regards, -- js suse labs
Hi, here, Thinkpad T450s, using TW and »full wayland«. Middle mouse ok, no more flickering since many months, kmail works, ... MS teams doesn't work under wayland, while zoom does. synergy not yet. Regards, -- Alexander
I have nothing more to add to Ondřej's last message, with which I agree in full. I'd would be grateful if the package maintainers would do us the favour of sharing their intentions. Best regards, Adrien
Why change the default in qtbase to "wayland;xcb" instead of refraining to touch qtbase at all, aligning on upstream?
This is a really good question. Maybe we didn't provide enough evidence that the upstream settings are actually working or maybe require further testing?
I don't think that any of this conversation should be taken personally. I don't see this as a hurtful comment on the work of maintainers who's work we all love and enjoy and I understand why the patch is there to begin with and I'm grateful for all the work you guys are put in to maintain Plasma on openSUSE. This whole convo is more towards bettering the Plasma Wayland situation on openSUSE. I can only speak for myself when I say that I didn't report issues previously with Plasma Wayland because it had pretty bad feedback from other distros as well. Also the upstream devs were pretty open about the state of Wayland on Plasma and my experience was equally bad. Why report something if it is known? However, in 5.20 and lately in 5.21 has been a lot of positive feedback around this, but my personal experience did not change for some reason. I still can't launch VSCode or Discord on a "Full Wayland" session along with a few other Flatpaks and see some graphical glitches. Yes, no X in the background. Anyhow only in the recent days this topic around the openSUSE patch lit the bulb in my head - along with a discussion with folks involved with Plasma upstream - that this might be the source of the problem. I personally have very limited amount of time or resources right now to do any kind of serious testing and I definitely can't afford a full distro installation for the sake of help "proving" that we would be better off at this point without a patched experience and be closer to the upstream UX intended by KDE. However, if Andres finished baking his plasma I'm going to test it and see if the situation is indeed that severe where a patch would be required to keep the UX satisfactory.
A premise, in the last versions, especially with the 5.21 the state of Plasma-Wayland has been much improved, there are still some problems, but today it is usable basic. I have always preferred the Full-Wayland session, because in my experience I find it better. I imagine that the nested plasma-wayland session in Xorg was created when Plasma-Full-Wayland was unusable. With the Full-Wayland session, however, some applications do not work, however I noticed that for example Chrome, now it also works in Full-Wayland, I don't know if the change concerns Chrome or if it concerns the session. These days I installed KDE neon to understand if there are differences, the only differences that I noticed at the usability level is in applications such as Firefox, which in OpenSUSE is disastrous, while in KDE neon works normally and other applications that do not start In OpenSUSE. I think we just need to understand what is best today and what works best. I take this opportunity to thank all the dev. of OpenSUSE that always make a great job. I don't have the truth in your pocket, the Wayland session offered by Neon differs little from the full-wayland session of OpenSUSE, but some things work better, but this is just my experience. Hello everybody. Il giorno gio 11 mar 2021 alle ore 08:31 Attila Pinter <adathor@opensuse.org> ha scritto:
I don't think that any of this conversation should be taken personally. I don't see this as a hurtful comment on the work of maintainers who's work we all love and enjoy and I understand why the patch is there to begin with and I'm grateful for all the work you guys are put in to maintain Plasma on openSUSE. This whole convo is more towards bettering the Plasma Wayland situation on openSUSE.
I can only speak for myself when I say that I didn't report issues previously with Plasma Wayland because it had pretty bad feedback from other distros as well. Also the upstream devs were pretty open about the state of Wayland on Plasma and my experience was equally bad. Why report something if it is known? However, in 5.20 and lately in 5.21 has been a lot of positive feedback around this, but my personal experience did not change for some reason. I still can't launch VSCode or Discord on a "Full Wayland" session along with a few other Flatpaks and see some graphical glitches. Yes, no X in the background. Anyhow only in the recent days this topic around the openSUSE patch lit the bulb in my head - along with a discussion with folks involved with Plasma upstream - that this might be the source of the problem.
I personally have very limited amount of time or resources right now to do any kind of serious testing and I definitely can't afford a full distro installation for the sake of help "proving" that we would be better off at this point without a patched experience and be closer to the upstream UX intended by KDE.
However, if Andres finished baking his plasma I'm going to test it and see if the situation is indeed that severe where a patch would be required to keep the UX satisfactory.
I just checked this on the pet VM on my personal laptop as I had been seeing VBoxClient errors there. It turns out the errors are only happening with Plasma X11 and not with either of the Wayland session types. I updated VirtualBox and the client tools to the latest release from from upstream make sure it wasn't just an issue of an outdated VirtualBox installation. My preference in general in the capacity of Linux enthustiast would be to have the target future state in Tumbleweed for canary testing. The desktop in general is not relevant to my professional use case, however. For that work, csnary testing such as f2fs is called for with the goal of hosting things like Rancher on a filesystem that is less chatty than XFS with its journalling. \\ For canary testing f2fs in Tumbleweed, KDE Wayland has been useful. It is complex enough to provide a non-trivial amount of use to the filesystem. In the 1990s, we would compile the kernel as the most effective way to test RAM when it was suspected as a problem. While I wouldn't mind if the VBoxClient error were eventually worked on for Plasma X11, one minute spent looking at this on my behalf would be a minute too long. I would prefer to see issues such as the default permissions of /var/lib/nobody (which are now enforced by a package) addressed, since things like that are relevant to the current enterprise use case.
In this bug Nate Graham is asking you to remove the patches... https://bugzilla.opensuse.org/show_bug.cgi?id=1185740 What else can we do or would be needed to prove that implementing the patch is just wrong and just causes problems?
Thank you Fabian, thank you KDE Team! Thank you, thank you, THANK YOU! https://build.opensuse.org/package/revisions/KDE:Unstable:Frameworks/plasma5...
Thank you Fabian and the oS KDE team for revision 2775 on https://build.opensuse.org/package/revisions/KDE:Unstable:Frameworks/plasma5.... As far as I can see that's the best outcome for both openSUSE and KDE. Recommending Plasma on oS will feel better than ever!
On Sat, Jun 26, 2021 at 1:03 PM Adrien Glauser <adrien.glauser@gmail.com> wrote:
One last thing: any idea when it will make it from the unstable branch to Factory?
Probably as soon as this lands: https://build.opensuse.org/request/show/902488 -- 真実はいつも一つ！/ Always, there's only one truth!
participants (19)
-
Aaron Puchert -
Adrien Glauser -
Alin Marin Elena -
Andrés Barrantes Silman -
Attila Pinter -
AW -
Carlo Coppa -
Cor Blom -
Fabian Vogt -
Frans de Boer -
Jason Craig -
Jiri Slaby -
Karl Ove Hufthammer -
Knurpht-openSUSE -
Luca Beltrame -
Lucie Charrier -
Neal Gompa -
Ondřej Růžička -
Peter Clark