Is wayland required now? [yes]

[jesnow]

Is wayland now required for mesa, qt6 and kde-plasma? I can't seem to get it to stop pulling it in. I'm trying to have a wayland-free system but gentoo isn't letting me.

Code: Select all

bartali /home/jesnow # emerge -DNua world -X=chromium

These are the packages that would be merged, in order:

Calculating dependencies... done!
Dependency resolution took 20.95 s (backtrack: 0/20).

[ebuild  N     ] dev-libs/wayland-1.23.1  USE="-doc -test" ABI_X86="(64) -32 (-x32)" 
[ebuild  N     ] media-libs/mesa-24.2.6-r2  USE="X llvm (opengl) proprietary-codecs wayland zstd -d3d9 -debug -lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -vulkan-overlay -xa" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="sse2" LLVM_SLOT="18 -15 -16 -17" VIDEO_CARDS="-d3d12 (-freedreno) -intel -lavapipe (-lima) -nouveau -nvk (-panfrost) -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware -zink" 
[ebuild   R    ] media-libs/libva-2.22.0  USE="-wayland*" 
[ebuild   R    ] dev-qt/qtgui-5.15.14  USE="-wayland*" 
[ebuild  N     ] dev-qt/qtwayland-5.15.14  USE="-compositor -debug -test -vulkan" 
[ebuild  N     ] kde-frameworks/kwindowsystem-5.116.0  USE="X -debug -doc -test -wayland" 
[ebuild   R    ] x11-libs/gtk+-3.24.41-r1  USE="-wayland*" 
[ebuild  N     ] dev-qt/qtbase-6.7.3-r2  USE="X concurrent cups dbus gui icu libinput libproxy network opengl sql sqlite ssl udev wayland widgets xml (zstd) -accessibility -brotli -eglfs -evdev -gles2-only -gssapi -gtk -journald -mysql -nls -oci8 -odbc -postgres -renderdoc -sctp -syslog -test -tslib -vulkan" 
[ebuild  N     ] dev-qt/qtwayland-6.7.3-r1  USE="-accessibility -compositor -qml -test -vulkan" 
[ebuild  N     ] kde-frameworks/kidletime-6.7.0  USE="X wayland -debug -doc -xscreensaver" 
[ebuild  N     ] kde-frameworks/kguiaddons-6.7.0  USE="X dbus wayland -debug -doc -test" 
[ebuild  N     ] kde-frameworks/kwindowsystem-6.7.0  USE="X wayland -debug -doc -test" 
[ebuild  N     ] kde-frameworks/kguiaddons-5.116.0-r1  USE="X dbus kf6compat -debug -doc -test -wayland" 

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by dev-qt/qtwayland-6.7.3-r1::gentoo
# required by kde-frameworks/kidletime-6.7.0::gentoo[wayland]
# required by kde-plasma/drkonqi-6.1.5-r1::gentoo
# required by @selected
# required by @world (argument)
>=dev-qt/qtbase-6.7.3-r2 wayland
# required by kde-plasma/kwin-6.1.5::gentoo
# required by kde-plasma/plasma-desktop-6.1.5-r1::gentoo
# required by @selected
# required by @world (argument)
>=media-libs/mesa-24.2.6-r2 abi_x86_32 wayland
# required by kde-frameworks/kauth-6.7.0::gentoo[policykit]
# required by kde-apps/kwalletmanager-24.08.1::gentoo
# required by @selected
# required by @world (argument)
>=kde-frameworks/kwindowsystem-6.7.0 wayland
# required by kde-plasma/kwin-6.1.5::gentoo
# required by kde-plasma/plasma-desktop-6.1.5-r1::gentoo
# required by @selected
# required by @world (argument)
>=kde-frameworks/kguiaddons-6.7.0 wayland
# required by kde-plasma/kwin-6.1.5::gentoo
# required by kde-plasma/plasma-desktop-6.1.5-r1::gentoo
# required by @selected
# required by @world (argument)
>=kde-frameworks/kidletime-6.7.0 wayland

Would you like to add these changes to your config files? [Yes/No] 

It looks like gwenview and spectacle have hard depends on wayland. I could do without those, but I don't know why they do that.

Am I out of luck?

[pingtoo]

Is wayland now required for mesa, qt6 and kde-plasma? I can't seem to get it to stop pulling it in.

Have you tried with USE=-wayland?

I'm trying to have a wayland-free system but gentoo isn't letting me.

Having wayland related stuff install on system is very different from running stuff *using* wayland. So does it matter?

You do know Gentoo does not develop these applications right? it is the upstream that moving its direction include wayland. Gentoo offer optionally for those that allow optionally enable. Should the upstream stop support optionally enable (mean if must always turn on) then the package will not have USE flag that have "wayland".

If you wish Gentoo developer do something (as in modify upstream direction) then you are out of luck. However since majority Gentoo packages are open source and the ebuild files also in source format, you can learn from ebuild and try to DIY exclude wayland from the package.

[szatox]

I think it is required for KDE now.
At least it recently stopped my attempt to try it out.

[jesnow]

I think you're right. I have given up before. Looks like I'm giving up again.

I think it is required for KDE now.
At least it recently stopped my attempt to try it out.

[jesnow]

The original post was my attempt to use -wayland. It isn't going to work.

KDE has hard wayland depends all over the place.

Code: Select all

kde-apps/gwenview-24.08.1 (dev-libs/wayland)
                          (dev-libs/wayland)
kde-apps/spectacle-24.08.1 (dev-libs/wayland)
                           (dev-libs/wayland)
kde-plasma/kscreenlocker-6.1.5 (dev-libs/wayland)
                               (dev-libs/wayland)
kde-plasma/kwayland-5.116.0 (>=dev-libs/wayland-1.15.0)
                            (>=dev-libs/wayland-1.15.0)
kde-plasma/kwayland-6.1.5 (>=dev-libs/wayland-1.15.0)
                          (>=dev-libs/wayland-1.15.0)
kde-plasma/kwayland-integration-6.1.5 (>=dev-libs/wayland-1.15)
                                      (>=dev-libs/wayland-1.15)
kde-plasma/kwin-6.1.5 (>=dev-libs/wayland-1.22.0)
                      (>=dev-libs/wayland-1.22.0)
kde-plasma/layer-shell-qt-6.1.5 (>=dev-libs/wayland-1.15)
                                (>=dev-libs/wayland-1.15)
kde-plasma/libkscreen-6.1.5 (dev-libs/wayland)
                            (dev-libs/wayland)
kde-plasma/libplasma-6.1.5 (>=dev-libs/wayland-1.15.0)
                           (>=dev-libs/wayland-1.15.0)
kde-plasma/plasma-desktop-6.1.5-r1 (dev-libs/wayland)
                                   (dev-libs/wayland)
kde-plasma/plasma-integration-6.1.5 (dev-libs/wayland)
                                    (dev-libs/wayland)
kde-plasma/plasma-workspace-6.1.5-r3 (>=dev-libs/wayland-1.15)
                                     (>=dev-libs/wayland-1.15)
kde-plasma/xdg-desktop-portal-kde-6.1.5 (>=dev-libs/wayland-1.15)
                                        (>=dev-libs/wayland-1.15)

Of course that's not gentoo's fault. Kde depends on what kde depends on. Mesa requires it too these days.


so the following wayland components are pulled in even though I never run wayland.

Code: Select all

bartali /home/jesnow # equery list wayland -f
 * Searching for wayland ...
[IP-] [  ] dev-libs/plasma-wayland-protocols-1.14.0:0
[IP-] [  ] dev-libs/wayland-1.23.1:0
[IP-] [  ] dev-libs/wayland-protocols-1.37:0
[IP-] [  ] dev-qt/qtwayland-5.15.14:5/5.15.14
[IP-] [  ] dev-qt/qtwayland-6.7.3-r1:6/6.7.3
[IP-] [  ] dev-qt/qtwaylandscanner-5.15.14:5
[IP-] [  ] dev-util/wayland-scanner-1.23.1:0
[IP-] [  ] kde-plasma/kwayland-5.116.0:5/5.116
[IP-] [  ] kde-plasma/kwayland-6.1.5:6
[IP-] [  ] kde-plasma/kwayland-integration-6.1.5:5
[IP-] [  ] x11-base/xwayland-24.1.4:0

That's just how it is I guess. It's like with required systemd and required graphical login managers. Decisions have been made upstream, and gentoo is among the last holdouts where any choice is possible. We can be grateful for that. I'm not going to file a bug or a feature request about it. Back in the mainframe day, backwards compatibility was a core principle. In fact you can find COBOL code running today unmodified from the 1960's. My mother worked on a subsystem of VM/CMS called HASP and though I can't prove it I think some of her code is still running in production systems today. But that's just not how the modern world rolls. "Hey we have a new thing that's way cool and everybody has to use it now."

Cheers,
Jon.

Is wayland now required for mesa, qt6 and kde-plasma? I can't seem to get it to stop pulling it in.

Have you tried with USE=-wayland?

I'm trying to have a wayland-free system but gentoo isn't letting me.

Having wayland related stuff install on system is very different from running stuff *using* wayland. So does it matter?

You do know Gentoo does not develop these applications right? it is the upstream that moving its direction include wayland. Gentoo offer optionally for those that allow optionally enable. Should the upstream stop support optionally enable (mean if must always turn on) then the package will not have USE flag that have "wayland".

If you wish Gentoo developer do something (as in modify upstream direction) then you are out of luck. However since majority Gentoo packages are open source and the ebuild files also in source format, you can learn from ebuild and try to DIY exclude wayland from the package.

[Goverp]

From the Gentoo News item about KDE 6

Plasma Wayland support has come a long way and therefore KDE developers have
decided to make it the default login session for Plasma 6, even if some
known papercuts[2] remain. For users affected too much by those, switching
to the still existing X11 session is as easy as selecting it in the display
manager of choice. Disabling USE="wayland" is *not* changing this default,
it will yield no dependency savings, and we advise against doing so. It does
not affect users' X11 sessions.

[Spanik]

It is required and the experience is worse than plain X11. Welcome to the future.

[CaptainBlood]

As far as KDE is concerned, is SDDM wayland ready back again?

Otherwise it would be infortunate to login KDE wayland using the X11 stack.

Thks 4 ur attention, interest & support.

[dmpogo]

It is required at installation (at least partially) but does not have to be used yet

[CaptainBlood]

Ok,

The question remains:

which GUI login manager to use for KDE wayland that wouldn't start X11 server?

Thks 4 ur attention, interest & support.

[dmpogo]

Ok,

The question remains:

which GUI login manager to use for KDE wayland that wouldn't start X11 server?

Thks 4 ur attention, interest & support.

Correct me if I am wrong.

Wayland by itself cannot do much, it requires a compositor, which under KDE is kwin. So the only way to avoid duplication of compositors in KDE and display manager (which needs to provide a welcome screen)
is for display manager to use kwin as a compositor. Which is what sddm in wayland configuration is trying to do. Given that sddm is kind of closely aligned with KDE, that will probably work eventually.

But for other display managers relyng on kwin may not be an obvious path.

In that sense, under pure wayland you do not have display capabilities before you launch at least part of your desktop environment (so why not all ?), so what is the point of display manager becomes unclear.

[Yamakuzure]

It is required and the experience is worse than plain X11. Welcome to the future.

Where exactly is the experience worse than plain X11 apart from a few extra dependencies pulled in?

[Hu]

It is required and the experience is worse than plain X11. Welcome to the future.

Where exactly is the experience worse than plain X11 apart from a few extra dependencies pulled in?

Remote GUI forwarding for Wayland ("X11 forwarding", in the X11 world) is not natively available in ssh, as far as I know. There are workarounds, but they require extra setup.

Screen sharing was broken for a long time, and since it requires special support from the compositor, it may work in some compositors and fail in others. More generally, it seems to me that there are too many useful things people would want to do that are optional features that any given compositor may support well, poorly, or not at all. This leads to significant variance in the quality of "Wayland" depending on the specific compositor chosen.

[gorg86]

Yes I got the same question as Yamakuzure. You compared Wayland to Lennartware, but I don't see the connection.

[rab0171610]

Remote Gui Forwarding works in Wayland using waypipe:

Code: Select all

waypipe ssh -YC -l username machinename

No additional setup was needed in my case other than installing waypipe.
If one machine is running X11 and the other Wayland, ssh will continue to work using this command but Gui Forwarding would be disabled.
The reason I did not like also running SDDM under Wayland is that SDDM did not exit like it does when run under X11 after logging into the desktop. That may be fixed now, but that disrupted the traditional respawn behavior that SDDM has under X11. It has been some time since I tested that scenario.

[Yamakuzure]

It is required and the experience is worse than plain X11. Welcome to the future.

Where exactly is the experience worse than plain X11 apart from a few extra dependencies pulled in?

Remote GUI forwarding for Wayland ("X11 forwarding", in the X11 world) is not natively available in ssh, as far as I know. There are workarounds, but they require extra setup.

Screen sharing was broken for a long time, and since it requires special support from the compositor, it may work in some compositors and fail in others. More generally, it seems to me that there are too many useful things people would want to do that are optional features that any given compositor may support well, poorly, or not at all. This leads to significant variance in the quality of "Wayland" depending on the specific compositor chosen.

No.

Where is using X11 with Wayland stuff installed via USE flags worse than "plain X11" without Wayland libraries and stuff installed (but not used)?

That Wayland itself is absolutely broken/bonkers/not-ready-yet in many places is well known.
One of my favorites is playing WebGL games.
X11: 144 FPS with <18ms ping.
Wayland: 5-20 FPS with 50+ ping.

Anyway, Plasma 6 works very well on X11 for the time being, so I won't complain. I start a Wayland session every couple of weeks to see whether I can switch, but that didn't happen, yet.

(I can live with WebGL in Chrome being bad, it isn't really Wayland-ready and vice-versa. But on my Intel+nvidia hybrid laptop, I do not have a mouse pointer on the external monitors under Wayland. I'd call that a show-stopper. )

[asturm]

Wayland by itself cannot do much, it requires a compositor, which under KDE is kwin. So the only way to avoid duplication of compositors in KDE and display manager (which needs to provide a welcome screen)
is for display manager to use kwin as a compositor. Which is what sddm in wayland configuration is trying to do. Given that sddm is kind of closely aligned with KDE, that will probably work eventually.

But for other display managers relyng on kwin may not be an obvious path.

Where did you get that impression? KWin is just one option. Weston is another. And then there's other things like greetd as alternative to SDDM ...

Don't invent problems where there are none.

[dmpogo]

Wayland by itself cannot do much, it requires a compositor, which under KDE is kwin. So the only way to avoid duplication of compositors in KDE and display manager (which needs to provide a welcome screen)
is for display manager to use kwin as a compositor. Which is what sddm in wayland configuration is trying to do. Given that sddm is kind of closely aligned with KDE, that will probably work eventually.

But for other display managers relyng on kwin may not be an obvious path.

Where did you get that impression? KWin is just one option. Weston is another. And then there's other things like greetd as alternative to SDDM ...

Don't invent problems where there are none.

Sure you can use other compositors. But it is a bit stupid to launch one compositor for a display manager, and then another for your desktop environment (presumably killing the first one ? and relaunching it again on logout ?
Not to mention that under SDDM you need to define, as far as I see, a compositor such as kwin-wayland by hand in configuration (maybe I am reading an old manual ? )

Under X there is a separation between display server, which is universal for a platform and is launched first, then display manager chooses the client that will be connected (traditionally, possibly remote, even without that, chooses desktop environment) and then launches a chosen client. Under wayland, when you need to select compositor from the beginning, which in many cases defines your desktop environment (who will run KDE without kwin or Gnome without mutter ?) , I do not see much of a point in display manager at all. It is not a problem, it is just an architecture where there is no separation of layers, and the point of graphical chooser in-between is unclear.

[pingtoo]

Wayland by itself cannot do much, it requires a compositor, which under KDE is kwin. So the only way to avoid duplication of compositors in KDE and display manager (which needs to provide a welcome screen)
is for display manager to use kwin as a compositor. Which is what sddm in wayland configuration is trying to do. Given that sddm is kind of closely aligned with KDE, that will probably work eventually.

But for other display managers relyng on kwin may not be an obvious path.

Where did you get that impression? KWin is just one option. Weston is another. And then there's other things like greetd as alternative to SDDM ...

Don't invent problems where there are none.

May be that is call visionary? Like iPad first came out when there is no such thing or even need.

It is a problem because there is a predecessor (X Display Manager) that can do just that function, therefor it is taken out for a comparison on why not.

[asturm]

I have no idea what you are talking about.

@dmpogo: Then don't use a DM? I fail to see where these questions are coming from, when you have all the options. I'd imagine you can easily run a Wayland compositor, even if it is not the one you choose in user session, on less resources than X11, so that's only a benefit?

[dmpogo]

I have no idea what you are talking about.

@dmpogo: Then don't use a DM? I fail to see where these questions are coming from, when you have all the options.

The original question was - how to use display manager purely under Wayland without having to run X11 ? My opinion - there is no great reason of having display manager under purely Wayland system at all, since you either have to
foresee in manual configuration your compositor which comes with DM, or run/switch between different compositors for no apparent profit. As I see you tend to agree ?

[asturm]

since you either have to foresee in manual configuration your compositor which comes with DM

No you don't. The packager shipping a DM will make sure the default configuration of it will have its runtime dependencies fulfilled, users may choose different configs/compositors.

[Spanik]

It is required and the experience is worse than plain X11. Welcome to the future.

Where exactly is the experience worse than plain X11 apart from a few extra dependencies pulled in?

Session restore doesn't work at all anymore, Dolphin has become slow as treacle, login takes a lot longer, video playback stutters from time to time... Haven't tried remote yet.

It uses now a Wayland to X11 bridge.

[asturm]

Session restore doesn't work at all anymore,

Known limitation since the old session restore was entirely an X11 function, and GNOME predictably weren't interested making a protocol standard worthy version of what they did as a replacement. Albeit "at all" is not quite correct, KDE added "limited" support to Plasma 6.

Dolphin has become slow as treacle, login takes a lot longer

Sounds like you have entirely other issues here. Why would you think that is Wayland related at all?

video playback stutters from time to time...

Then better find out what's wrong with your video settings.

It uses now a Wayland to X11 bridge.

What is "it" in that sentence? Context?

[Spanik]

Session restore doesn't work at all anymore,

Known limitation since the old session restore was entirely an X11 function, and GNOME predictably weren't interested making a protocol standard worthy version of what they did as a replacement. Albeit "at all" is not quite correct, KDE added "limited" support to Plasma 6.

You call putting all previous screens at 0;0 on top of each other "support"?

Dolphin has become slow as treacle, login takes a lot longer

Sounds like you have entirely other issues here. Why would you think that is Wayland related at all?

Because with all previous versions it worked fine and since the Wayland version it happens while nothing else on the pc changed?

video playback stutters from time to time...

Then better find out what's wrong with your video settings.

Same answer, fine with X11 only support

It uses now a Wayland to X11 bridge.

What is "it" in that sentence? Context?

[/quote]
The current version of KDE/Plasma 6.1.5, framework 6.6.0.