1. Logins don't work reliably. I use KDE/SDDM and when logging in it
appears to start on a new VT and sometime it doesn't start. Or it will
start the new VT and fail to switch to it, leaving a text console and a blinking cursor. This didn't happen when using X11.
Is it just me or is wayland nowhere near primetime?
On 05/08/2024 23:56, Daniel Frey wrote:
I'm glad I'm not the only one having problems. It does make me wonder though if the discrete video card (nvidia) is the cause of some/most of these problems.
If I were to 'guess', I think it's the Nvidia drivers and less to do
with Wayland implementation.
I have an Nvidia RTX 20-series and Wayland sessions generally exhibit
mostly the same issues as yours - flickering and/or
freezing/unresponsive panels, random KDE crashes, and general
instability. Sleep simply doesn't work at all properly with a wayland
session and my PC freezes, requiring a reboot. Mind you, this is a
modern system with an X670E chipset, but certainly not modern enough to
still have launch issues.
It's the same with both the proprietary Nvidia driver and the new 1st
party open-source driver that comes with the 555-series drivers. I've
not tried nouveau - it's on my list, but I sometimes need CUDA so not
yet sure how this is going to wor
k out without a driver swap.
They don't happen in X11 though.
Same here. X11 is mostly stable for nvidia except for suspend/resume
which can often not suspend at all, requiring multiple attempts, or
borking up the screen resolution.
I say 'guess' above in quotes because Nvidia have notoriously bad
drivers for Linux and Wayland support has been pretty non-existent _and_
I've been using Wayland as a daily driver with AMD (current laptop) and
Intel GPUs (previous laptop) for about 2 years without any major issues outside of minor known KDE bugs which have got hoovered over time with updates.
Furthermore, on my workstation (with the Nvidia GPU) all
problems, Wayland and the X11 sleep issue , essentially disappear as
soon as I wire things up to the onboard built-in Ryzen GPU and switch to
the "amdgpu" driver and Wayland is rock solid - no sleep/resume issues either.
So... yes, in my experience Nvidia is just crap on Linux and, frankly,
given where they
seem to be headed wrt their business priorities, I
don't see this getting any better any time soon. I think my next GPU
upgrade, whenever that may be, will be an AMD.
I'm curious to see how KDE 6 will behave once stabilised. It's supposed
to have further Wayland improvements, but I'm not holding my breath as I don't think it's necessarily KDE's problem.
- Victor
Is it just me or is wayland nowhere near primetime?
I did a switchover to systemd/wayland some time ago and it seemed to
solve some problems I had.
The problem is it also came with so many more issues than it fixed:
1. Logins don't work reliably. I use KDE/SDDM and when logging in it
appears to start on a new VT and sometime it doesn't start. Or it will
start the new VT and fail to switch to it, leaving a text console and a blinking cursor. This didn't happen when using X11.
2. Sometimes video hardware acceleration just doesn't work. Now I do
have a discrete nVidia card with the proprietary driver, but I switched
to nouveau and it didn't work either. Again, not an issue in X11.
I have a nVidia RTX 3070 Ti.
3. I sleep/resume a lot, wayland seems to be quite buggy on resume. As
in, the other three issues listed here are far more likely to occur
after a sleep/resume, but they do happen even after rebooting and being
on the PC most of the day.
4. This is the big one, the panel in KDE hangs intermittently. The clock
will freeze and the entire panel is unresponsive (but weirdly enough,
KDE doesn't realize it's not responding.) I've tried killing and
restarting the process and that doesn't always fix it either as it
becomes disconnected with any open processes and it's not possible to resolve. Either have to logout or reboot.
I've switched back to X11 for now and have been using it for over a
week. I managed to figure out how to set up multimonitor for now (both
on the KDE desktop and in SDDM) and I haven't had any of these issues.
For the record, I typically use the computer a few times a day during
the week and sleep/resume, and longer on weekends.
After much googling and experimenting, I can't seem to make these issues
go away... which got me wondering if someone else has experienced any of these.
I have done hardware tests (load testing, RAM tests, etc) - all are clear.
-Dan
On 05/08/2024 18.30, Daniel Frey wrote:
Is it just me or is wayland nowhere near primetime?
There are still issues with wayland, not sure how up to date this page is: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
My SailfishOS based phone uses wayland and on that it's been working fine, on my desktop with a nVidia RTX I haven't managed to even login into a wayland session,
but on my laptop with i915 it works fine most of the time and it leave
me think that the developers behind wayland are mainly using intel
graphics cards and then blame the graphics driver when things don't
work on other hardware.
I would say for general use wayland ain't up for it's task, if you have the right hardware and you mainly use the browser, then it works.
On 05/08/2024 17:30, Daniel Frey wrote:
1. Logins don't work reliably. I use KDE/SDDM and when logging in it appears >> to start on a new VT and sometime it doesn't start. Or it will start the new >> VT and fail to switch to it, leaving a text console and a blinking
cursor. This didn't happen when using X11.
Last I investigated, sddm had a *hard* dependency on X11. So even if you're running a Wayland system (like I am) you need X installed so that sddm will work.
Daft, I know, but that seems to be the way things are at the moment ...
Is it just me or is wayland nowhere near primetime?
I did a switchover to systemd/wayland some time ago and it seemed to solve some
problems I had.
The problem is it also came with so many more issues than it fixed:
1. Logins don't work reliably. I use KDE/SDDM and when logging in it appears to
start on a new VT and sometime it doesn't start. Or it will start the new VT and fail to switch to it, leaving a text console and a blinking cursor. This didn't happen when using X11.
2. Sometimes video hardware acceleration just doesn't work. Now I do have a discrete nVidia card with the proprietary driver, but I switched to nouveau and
it didn't work either. Again, not an issue in X11.
I have a nVidia RTX 3070 Ti.
3. I sleep/resume a lot, wayland seems to be quite buggy on resume. As in, the
other three issues listed here are far more likely to occur after a sleep/resume, but they do happen even after rebooting and being on the PC most
of the day.
4. This is the big one, the panel in KDE hangs intermittently. The clock will freeze and the entire panel is unresponsive (but weirdly enough, KDE doesn't realize it's not responding.) I've tried killing and restarting the process and
that doesn't always fix it either as it becomes disconnected with any open processes and it's not possible to resolve. Either have to logout or reboot.
I've switched back to X11 for now and have been using it for over a week. I managed to figure out how to set up multimonitor for now (both on the KDE desktop and in SDDM) and I haven't had any of these issues. For the record, I typically use the computer a few times a day during the week and sleep/resume,
and longer on weekends.
After much googling and experimenting, I can't seem to make these issues go away... which got me wondering if someone else has experienced any of these.
I have done hardware tests (load testing, RAM tests, etc) - all are clear.
On 8/5/24 09:58, Wols Lists wrote:
On 05/08/2024 17:30, Daniel Frey wrote:
1. Logins don't work reliably. I use KDE/SDDM and when logging in it
appears to start on a new VT and sometime it doesn't start. Or it will
start the new VT and fail to switch to it, leaving a text console and
a blinking cursor. This didn't happen when using X11.
Last I investigated, sddm had a *hard* dependency on X11. So even if
you're running a Wayland system (like I am) you need X installed so that sddm will work.
Daft, I know, but that seems to be the way things are at the moment ...
Cheers,Wol
I even tried enabling wayland for sddm (which is apparently
experimental) but it didn't help either.
Both X11 and wayland appear to be installed.
I just find it odd that a lot of DEs (and distros) are defaulting to
wayland when it's horribly broken.
Dan
"J. Aho" <[email protected]> writes:
On 05/08/2024 18.30, Daniel Frey wrote:
Is it just me or is wayland nowhere near primetime?
There are still issues with wayland, not sure how up to date this page is: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
it's either out of date or fearmongering. I'd presume the former if not
for the first emphasised paragraph of the post: "DO NOT USE A WAYLAND SESSION! Let Wayland not destroy everything and then have other people
fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone".
but, each "point" it makes can individually be debunked also. I'm not
very interested in doing that beyond oneliners though (which is
apparently enough for the author of the original post).
- Wayland breaks setting the window position - yes, intentionally,
wayland is declarative wrt window positioning (you might notice that
if you right click, the popup position is as you'd expect - this is
because the client tells the compositor where /relative to a surface/
it wants some other surface to appear, rather than a global position).
have a lovely day
--
Arsen Arsenović
"J. Aho" <[email protected]> writes:
On 05/08/2024 18.30, Daniel Frey wrote:
Is it just me or is wayland nowhere near primetime?
There are still issues with wayland, not sure how up to date this page is: >> https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
it's either out of date or fearmongering. I'd presume the former if not
for the first emphasised paragraph of the post: "DO NOT USE A WAYLAND
SESSION
- Wayland breaks screen recording applications - this is false, either
1) screen recording works via portals, or 2) screen recording works
via xwaylandvideobridge
- Wayland complicates server-side window decorations - CSD seems logical
to me, at least in large part, so I'm not sure this actually matters.
however, I know that SSD support exists.
- Wayland breaks window managers - I'm not sure what they mean here
there's a new graphics stack because the old one didn't work, and I'm
not sure where this kind of response to it comes from - it seems similar
to the systemd debacle. see also
https://www.youtube.com/watch?v=GWQh_DmDLKQ (by a former X developer,
so, someone with qualifications)
what these posts /also/ lack is enthusiastic contributors who'll
actually pick up the mantle of maintaining and improving X.
I have been using wayland for probably four or so years now, and I've
only so far missed a standard for global shortcuts (note, a _standard
for it_, not a hack-job allowing clients to listen to keystrokes
globally and react to them, leading to weird conflicts and fragmented configuration; something integrated into desktops, that's not a job of individual clients to implement, so, really, I'm missing that in X also).
My SailfishOS based phone uses wayland and on that it's been working fine, on
my desktop with a nVidia RTX I haven't managed to even login into a wayland >> session,
hmm, on my 1050Ti PC I run kde plasma just fine. I don't know anyone
with an RTX card to ask them if it works for them, though - but it could
be some misconfiguration (you need some USE flags on the nvidia drivers
IIRC, and some compositors, like sway, require an extra flag).
On 06/08/2024 15.56, Arsen Arsenović wrote:
"J. Aho" <[email protected]> writes:
On 05/08/2024 18.30, Daniel Frey wrote:it's either out of date or fearmongering. I'd presume the former if not
Is it just me or is wayland nowhere near primetime?
There are still issues with wayland, not sure how up to date this page is: >>> https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
for the first emphasised paragraph of the post: "DO NOT USE A WAYLAND
SESSION
It's quite possible as I didn't really read the beginning of the page, just saw
some stuff mentioned that I had seen on other places.
- Wayland breaks screen recording applications - this is false, either
1) screen recording works via portals, or 2) screen recording works
via xwaylandvideobridge
I think there was some merit to that claim some years ago, I'm not into screen
recording so not sure.
- Wayland complicates server-side window decorations - CSD seems logical
to me, at least in large part, so I'm not sure this actually matters.
however, I know that SSD support exists.
I have to say I'm quite anti-CSD myself, much for the lack of having close on left side and minimize/maximize on the right side of the window but also the horror of everyone want to make their own look on the CSD which makes everything to look like microsoft-windows where even microsoft's own application uses different look.
I don't see the CSD as a specific wayland issue, it has the same issue in X11 too.
- Wayland breaks window managers - I'm not sure what they mean here
I guess that could be related to X11 window managers that do not support wayland, but it's like a qt3 application don't run on a system with only qt6 libraries.
there's a new graphics stack because the old one didn't work, and I'm
not sure where this kind of response to it comes from - it seems similar
to the systemd debacle. see also
https://www.youtube.com/watch?v=GWQh_DmDLKQ (by a former X developer,
so, someone with qualifications)
what these posts /also/ lack is enthusiastic contributors who'll
actually pick up the mantle of maintaining and improving X.
Sure it's far easier to say what "you" think don't work than code.
There was a X11 variant where they had stripped away loads of support for old stuff, just don't remember the name (most variants of X11 had been forgotten),
and they had some improvements too, but if you don't get picked up by a major distribution, you will definitely have a lot harder to break thru to the masses.
I have been using wayland for probably four or so years now, and I've
only so far missed a standard for global shortcuts (note, a _standard
for it_, not a hack-job allowing clients to listen to keystrokes
globally and react to them, leading to weird conflicts and fragmented
configuration; something integrated into desktops, that's not a job of
individual clients to implement, so, really, I'm missing that in X also).
Just make a patch and submit it ;)
My SailfishOS based phone uses wayland and on that it's been working fine, onhmm, on my 1050Ti PC I run kde plasma just fine. I don't know anyone
my desktop with a nVidia RTX I haven't managed to even login into a wayland >>> session,
with an RTX card to ask them if it works for them, though - but it could
be some misconfiguration (you need some USE flags on the nvidia drivers
IIRC, and some compositors, like sway, require an extra flag).
I have been using KDE since Havoc called me a troll for pointing out that you can't have configuration options that has the exact same name but does different things.
I have rebuilt the whole system, I have tried with other distros, the same result, I do not get wayland to work on the nVidia, not sure how many different
howto's I have tried to follow, but on the laptop not much of an issue at all but as I pointed out it's an intel GPU. And my old mobile it works fine too.
So, is it possible in Wayland to record a configuration of windows,
their sizes and positions, then restore these on starting a program
again? If not, that would appear to be a design bug in Wayland. What
am I missing?
On 8/6/24 06:56, Arsen Arsenović wrote:
"J. Aho" <[email protected]> writes:
- Wayland breaks screensavers - ironically, those never worked on X, but
do on wayland, because the compositor can actually redirect keys
properly rather than trying to patchwork around X
I actually forgot about this one - the screensaver was crashing all the time causing me to use loginctl to unlock the session.
That hasn't happened even once in the last 8 days since using X11.
Dan
That's indeed the case, XDG and freedesktop and the X consortium being
behind Wayland certainly helped adoption.
Hello, Arsen.
On Tue, Aug 06, 2024 at 15:56:40 +0200, Arsen Arsenović wrote:
"J. Aho" <[email protected]> writes:
On 05/08/2024 18.30, Daniel Frey wrote:
Is it just me or is wayland nowhere near primetime?
There are still issues with wayland, not sure how up to date this page is: >> > https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
it's either out of date or fearmongering. I'd presume the former if not
for the first emphasised paragraph of the post: "DO NOT USE A WAYLAND
SESSION! Let Wayland not destroy everything and then have other people
fix the damage it caused. Or force more Red Hat/Gnome components (glib,
Portals, Pipewire) on everyone".
but, each "point" it makes can individually be debunked also. I'm not
very interested in doing that beyond oneliners though (which is
apparently enough for the author of the original post).
I'm interested in one of the points you address in particular, namely:
[ .... ]
- Wayland breaks setting the window position - yes, intentionally,
wayland is declarative wrt window positioning (you might notice that
if you right click, the popup position is as you'd expect - this is
because the client tells the compositor where /relative to a surface/
it wants some other surface to appear, rather than a global position).
This has caused problems for Emacs, though I can't remember exactly how,
so I'm guessing. On restarting a saved Emacs session, it's necessary to
have the windows the same size, in the same place they were on saving
the session. This would appear to be difficult in Wayland.
You say "yes, intentionally, wayland is declarative wrt window
positioning". What does that mean when you replace abstract words like "declarative" with concrete sentences? What is declaring what to what
else in this context, and what does that have to do with not being able
to position windows?
Later on, you say "where /relative to a surface/". I think "surface" is
a word with particular meaning in Wayland, and using it in a Gentoo list without explanation is less than helpful. What does "surface" mean in
this context? Is the entire screen such a "surface"?
So, is it possible in Wayland to record a configuration of windows,
their sizes and positions, then restore these on starting a program
again? If not, that would appear to be a design bug in Wayland. What
am I missing?
Last I investigated, sddm had a *hard* dependency on X11. So even ifyou're running a Wayland system (like I am) you need X installed so that
Hi,
On 6/8/24 02:58, Wols Lists wrote:
Last I investigated, sddm had a *hard* dependency on X11. So even if
you're running a Wayland system (like I am) you need X installed so that
sddm will work.
That's not quite correct; it's been possible to run SDDM directly as a Wayland session for quite a while. I have several machines that use `kwin_wayland`: https://wiki.gentoo.org/wiki/SDDM#Kwin
Since Plasma 6 I haven't noticed any issues, it used to be a _little_
weird for Plasma 5 if you (e.g.) logged out.
Cheers,
Matt
On 06/08/2024 19:31, Alan Mackenzie wrote:
So, is it possible in Wayland to record a configuration of windows,
their sizes and positions, then restore these on starting a program
again? If not, that would appear to be a design bug in Wayland. What
am I missing?
That - unlike X - is because windows cannot say where they are going to
go. They can *ask* where they want to go, which isn't the same thing.
Iirc, X behaves like Windows, which means applications can *seize*
focus, which drives me up the wall on occasion at work. I'll have an
Excel macro running, which takes maybe 3 or 4 minutes. So I go into
let's say Slack. Excel triggers something (google drive?) which grabs
focus and disappears, so all of a sudden I *think* I'm gaily typing into Slack. But focus has been stolen and I'm typing into a vacuum -
EXTREMELY frustrating, especially as I don't actually know what's going on.
In Wayland, you can't steal focus. But as a side effect, it's Wayland
that controls the window, not the application. So Wayland is more
secure, but that comes with unavoidable side effects that you don't like...
Cheers,
Wol
Hello, Wol.
On Tue, Aug 06, 2024 at 23:08:42 +0100, Wol wrote:
On 06/08/2024 19:31, Alan Mackenzie wrote:
So, is it possible in Wayland to record a configuration of windows,
their sizes and positions, then restore these on starting a program
again? If not, that would appear to be a design bug in Wayland. What
am I missing?
That - unlike X - is because windows cannot say where they are going to
go. They can *ask* where they want to go, which isn't the same thing.
How does it differ in practice? Under what circumstances would a
request to display a window at a particular place result in it being displayed somewhere else?
Iirc, X behaves like Windows, which means applications can *seize*
focus, which drives me up the wall on occasion at work. I'll have an
Excel macro running, which takes maybe 3 or 4 minutes. So I go into
let's say Slack. Excel triggers something (google drive?) which grabs
focus and disappears, so all of a sudden I *think* I'm gaily typing into
Slack. But focus has been stolen and I'm typing into a vacuum -
EXTREMELY frustrating, especially as I don't actually know what's going on.
I don't understand what these issues with focus have to do with
positioning a window. Though I can appreciate them causing problems.
There would appear to be a clash between Wayland running within a
GNU/Linux running as a Windows subsystem, and the Windows itself -
presumably Windows allows a Windows application to steal focus from a
Wayland application in this situation.
In Wayland, you can't steal focus. But as a side effect, it's Wayland
that controls the window, not the application. So Wayland is more
secure, but that comes with unavoidable side effects that you don't like...
How does Wayland controling the Window lead to an application program's inability to position it? I can't see the connection.
Just as a bit of context; I've not yet tried Wayland, and for most of my
work (including Emacs) use a Linux console.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 169:31:30 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,838 |