Trying to run KDE 6 Plasma with Wayland....

Why do you use sddm at all? Will you encounter the same problems that you've been describing if you load the GUI by typing dbus-run-session ck-launch-session startplasma-wayland on the command line?
 
Oleg_NYC said:
Why do you use sddm at all? Will you encounter the same problems that you've been describing if you load the GUI by typing dbus-run-session ck-launch-session startplasma-wayland on the command line?
Click to expand...
That's worth a try... I'm not sure what to do about a lockscreen, though, that is part of the user experience that I do see as important.
 
Oleg_NYC said:
Why do you use sddm at all? Will you encounter the same problems that you've been describing if you load the GUI by typing dbus-run-session ck-launch-session startplasma-wayland on the command line?
Click to expand...

Trying to run service sddm stop does result in a messy spiral that is only likely to be resolved with a reboot. There's an error message that constantly repeats:

[drm ERROR : dc_dmub_srv_cmd_run_list] Error queueing DMUB command: status=2

Update: After that ill-fated service sddm stop, I turned off SDDM in /etc/rc.conf, and rebooted.

Logged in at command-line.

That same error line still spits out onto the console, so I had to type in blind the ck-launch-session dbus-run-session startplasma-wayland command. That got me into a Plasma Wayland session successfully, no SDDM needed.

BUT...

Then I let the screen time out and get locked. A minute later, the monitor got turned off. So far, normal, right?

Wiggling the mouse got me back to the lockscreen, but after that, I lost keyboard and mouse.

This time around, I don't exactly have the option to run service sddm restart - SDDM is turned off. I can only SSH in to reboot.

So yeah, Display Management is actually a sore necessity here...
 
I can't reproduce the same problem if I use the lockscreen feature, turn-off-the-monitor feature, or sleep feature. sddm only got in my way; I played with it for a few minutes, and uninstalled it.
 
Oleg_NYC said:
I can't reproduce the same problem if I use the lockscreen feature, turn-off-the-monitor feature, or sleep feature. sddm only got in my way; I played with it for a few minutes, and uninstalled it.
Click to expand...
Even with reduced time limits for turning off the monitor and activating the lockscreen:

Even without SDDM:

it's seriosly not possible to reproduce my problem if my steps get reproduced?

My conclusion based on that information would be that this could be due to the difference in the GPUs... Seems like authentication got solved, but Display Management is still the stubborn, missing link.
 
Yes, I can't reproduce it. If I set "Turn off screen" to "1 minute", "When locked: Immediately", and set "Lock screen automatically" to "1 minute", I will be able to unlock the screen later and continue using the GUI with the keyboard/mouse.
 
There was an SDDM update. The ctrl-c bug seems to be fixed. I'm using wayland on my intel system and I can use ctrl-c without it crashing now.

EDIT: Only issues are wireless mouse timing is laggy and coming back from a virt terminal goes to a black screen with a mouse pointer. Touchpad is smooth, don't know about wired mouse. But for some reason wireless mouse is laggy.
 
LibreQuest said:
There was an SDDM update. The ctrl-c bug seems to be fixed. I'm using wayland on my intel system and I can use ctrl-c without it crashing now.
Click to expand...
Sorry, that update happened nearly a week ago... the current showstopper is power management and display management (turning off the screen). If you're interested in following along, the details start on page 27 of this thread.

I'm on all-AMD hardware. I guess I'm stuck SSH-ing in from the side and restarting SDDM when the screen times out and turns itself off.

Without taking power management and display management into consideration, KDE on Wayland is actually quite usable. Would be nice to build a sturdy bridge that finishes the job for users of AMD hardware.
 
astyle said:
Sorry, that update happened nearly a week ago... the current showstopper is power management and display management (turning off the screen). If you're interested in following along, the details start on page 27 of this thread.

I'm on all-AMD hardware. I guess I'm stuck SSH-ing in from the side and restarting SDDM when the screen times out and turns itself off.

Without taking power management and display management into consideration, KDE on Wayland is actually quite usable. Would be nice to build a sturdy bridge that finishes the job for users of AMD hardware.
Click to expand...

A chatbot might give you code that solves your problem. I don’t have an AMD GPU, so I wouldn’t be able to test any AMD-specific code even if a chatbot gave it to me.
 
Oleg_NYC said:
A chatbot might give you code that solves your problem. I don’t have an AMD GPU, so I wouldn’t be able to test any AMD-specific code even if a chatbot gave it to me.
Click to expand...
Yeah, but I'm a rank-and-file user who would have no idea how to talk to a chatbot so that it spits out a patch that actually solves a problem. I still find it amazing that you were able to get ChatGPT to produce actually pertinent patches that actually work and solve the problem (even if ultimately only partially), let alone in such a short amount of time.

Well, this is how Open Source works, after all.
 
I've been running wayland on my intel system for a few days. The screen goes black when it times out but if I move the mouse it comes back to the lock screen. I can login as usual same as on X11.
 
Update: discovered that the greeter may be the problem here...

on my end, SDDM starts on Xorg.

It successfully logs me into a Plasma Wayland session.

When I get kicked out via lockscreen, I end up looking at SDDM again. But no keyboard/mouse.

I look at Xorg.0.log - and sure enough, my keyboard/mouse get dropped/removed. Seems like I need to tell SDDM to freaking NOT do that. Trying to start SDDM with a different Wayland compositor - no go, a long research project.

If that rings any bells, like how to edit a .conf file, please post in here!

I am open to chatbot help, too.

At least I now know this has nothing to do with AMD-specific hardware - properly configuring the SDDM daemon should be plenty.
 

Attachments

But earlier, you implied that your mouse/keyboard become non-functional after the lockscreen situation even if you don't use sddm at all and load Plasma by typing dbus-run-session ck-launch-session startplasma-wayland instead.
 
Oleg_NYC said:
But earlier, you implied that your mouse/keyboard become non-functional after the lockscreen situation even if you don't use sddm at all and load Plasma by typing dbus-run-session ck-launch-session startplasma-wayland instead.
Click to expand...
Yeah, I wrote that, but my troubleshooting skills suck right now. Just because some things happened in sequence, that does not necessarily means they are related. In this case, my correlation was just me flying blind.

At some point I'll probably get frustrated enough with myself to do some disciplined troubleshooting via divide-and-conquer, time-consuming research, and some careful notes.

Right now, got stuff IRL on my plate, so I'm just hoping somebody smarter than me will point out something stupid that I just missed.
 
Konqueror and Falkon both break and dump core on my 6.5.0 installation. Launching from command-line told me why - they use a deprecated API, and were not properly ported to the 6.5.0 release. I'm not seeking patches for those, I have bigger fish to fry - properly telling SDDM (which still starts under Xorg) to stop dropping my keyboard and mouse so blatantly. Or at least restart itself if that happens.
 
astyle said:
Konqueror and Falkon both break and dump core on my 6.5.0 installation. Launching from command-line told me why - they use a deprecated API, and were not properly ported to the 6.5.0 release. I'm not seeking patches for those, I have bigger fish to fry - properly telling SDDM (which still starts under Xorg) to stop dropping my keyboard and mouse so blatantly. Or at least restart itself if that happens.
Click to expand...

In my own experience, the mouse was non-functional on Xorg (including sddm) until I deleted 40-libinput.conf from /usr/local/share/X11/xorg.conf.d .
 
Does PR 288627 seem to be related with SDDM issues here?

Just searched on Bugzilla, as I'm not using any display manager like SDDM and XDM to login (console login, then startx. Not using Wayland compositor except for short period of times resulted in unsuccessfull).
 
T-Aoki said:
Does this commit related?
Click to expand...
I'm actually still on the code that I downloaded from the Area 51 repo that makc_ shared a link to in post #640 of this thead... And yeah, I have that patch - I had it applied before playing with the code and observing/writing about all the SDDM issues on my end in the last week.

I'm still playing with SDDM and dumping out my observations - maybe somebody knowledgeable will see it and notice a simple stupid config detail that I'm just blind to...
 
You must log in or register to reply here.
Back
Top