Plasma Wayland stopped working - how can I investigate the cause?

[espinosa_cz]

I was quite happy user of Plasma on Wayland. It came automatically with KDE Plasma 6.0 and worked out of the box. But some time ago, I suspect after update to KDE Plasma 6.1, it stopped working. When I select Plasma on Wayland in the system login screen, in SDDM, it shows briefly a black window and then returns back to SDDM.

I was waiting if some system update would fix it. But it’s not happening so I guess I have to start digging around myself.

I do have Nvidia GPU, in addition to Intel iGPU. I have Nvidia drivers installed and there was at least one Nvidia driver update in the meantime.
I was always assuming that the Wayland used the iGPU.

Where I can find what was the error?
Which log I should look into?

[deano_ferrari]

A couple of things to try…

1. I suggest creating a new user, and then try to start a Plasma Wayland session as that user. Create the ‘test’ user account with YaST via a VT (no graphical session required)…

sudo yast

Navigate to Security and Users > User and Group Management > Add

Follow the prompts given. When done see if you login as that user form SDDM.

2. From a VT logged in as a regular user, you can try starting Plasma Wayland by hand like this

dbus-run-session startplasma-wayland > wayland.log

and if necessary the wayland.log can be checked for errors.

FWIW, a similar thread with the diagnostic steps that can be tried…

Wayland will not start

I cannot get Wayland to start on logging into KDE. When I attempt to log into Plasma on Wayland, I get a black screen for a little while and then the login screen reappears. I can log into Plasma on X11 with no problem. In the warning log I receive many messages along the lines of : This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.#012#012Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, of…

[Svyatko]

Post

inxi -aFz

[espinosa_cz]

I can run Wayland now. I’m writing this from Plasma Wayland. Nice.
Thank you all for your help.

In the end just a bit of system housekeeping did the trick.
What I did:

• In Yast, I found that some Mesa packages are from Packman repo (?).
  And on top of that those versions were orphaned, not in any repo any more. The versions were marked in red in Yast.
  I replaced them with versions available in core openSuse Slowroll repo, using “update unconditionally”. Which effectively did a downgrade.
• Disabled Plymouth. I had additional issues with Plymouth; it relates to tiny fonts in virtual consoles on my hi-res screen. Plymouth surprisingly conflicts with the font set via vconsole.conf. And there is no way around. See details in thread: Setting console font via /etc/vconsole.conf doesn't has no effect, my virtual console fonts are still super tiny - #12 by espinosa_cz.
  I disabled Plymouth by adding plymouth.enable=0 to Kernel Parameters through Yast Bootloader config UI.
• Also I set nosimplefb=0 in kernel boot parameters. It was nosimplefb=1 before. I have no idea what nosimplefb boot kernel parameter exactly does; it can be some kind of relict I keep rolling from old times. I haven’t re-installed openSuse on this laptop for last 2 years or so. I’m not sure it this is any way relevant to the Wayland issue.

…something from above fixed my issue.

FYI, the mismatched, orphaned, reportedly from Packman repo, Mesa packages were:

• Mesa-libEGL1
• Mesa
• Mesa-libGL1
• Mesa-libGLESv2-devel
• Mesa-libGL-devel
• Mesa-dri
• Mesa-gallium
• Mesa-KHR-devel
• Mesa-libEGL-devel

[deano_ferrari]

An inconsistent Mesa environment would for sure break a graphical desktop environment.

[espinosa_cz]

Packman repo still offers its own versions of Mesa:

Why is that? That doesn’t look safe.
And their version appears higher:
Mesa 24.1.3-390.1 (Slowroll) vs Mesa 24.1.3-1699.397 (Packman).
Same issue can happen to anyone.

[deano_ferrari]

A similar earlier discussion:

Mesa Conflict (Packman vs OpenSUSE)

Following my attempt to execute ‘zypper dup’ today in Tumbleweed, I encountered the following conflict. It appears that I have a newer repository installed from ‘opi codecs’ compared to the incoming upgrade (OpenSUSE). I’m unsure if this issue will resolve itself given enough time or if there’s a current workaround. I understand that one solution could be to remove Mesa and replace it with the OpenSUSE version, but that would also remove the installed codec support via ‘opi’. Any assistance in n…

[Svyatko]

@espinosa_cz

Why is that? That doesn’t look safe.

Because some people want HW decoding of proprietary codecs, which is unavailable with open drivers.