I have tried it now. I went to the TTY, stopped SDDM, and then ran this command
/usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/ck-launch-session /usr/local/bin/startplasma-waylandHaving the non-root user in video group is a correct move in any event.
Thanks for taking a look!I don't have Qemu experience, only VirtualBox. But if a GPU is virtualized, then yeah, it's gonna beSo you think this might e.g. be some problem of it trying to use the real GPU (inaccesible) rather than llvmpipe, inside Qemu?
Interesting.
llvmpipe.
FreeBSD-ports: {
url: "pkg+https://pkg.FreeBSD.org/${ABI}/latest",
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
FreeBSD-ports-kmods: {
url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest",
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}
FreeBSD-base: {
url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_latest",
mirror_type: "srv",
signature_type: "fingerprints",
fingerprints: "/usr/share/keys/pkg",
enabled: yes
}What does that have to do with making sure the port runs correctly on Wayland? This thread is about addressing papercuts and showstoppers, and which versions they apply to. Packaging issues like this are best addressed in the Forums section titled "Installation and Maintenance of Ports and Packages". You'll find it on the front page of the Forums.
How to configure SDDM to start this session?
Exec=/usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/ck-launch-session /usr/local/bin/startplasma-waylandI'm experiencing the same. But not only plasmashell, sddm too: according to truss output both seems to be in a loop executing fstatat() on four files (happens with both Xorg and Wayland session):
Ok, just solved it!
The sequence is incorrect here... the
/usr/local/bin/ck-launch-session comes first, and then the /usr/local/lib/libexec/plasma-dbus-run-session-if-needed... At least that was the case last time I tried to run Plasma Wayland from command-line. You also gotta have the following folder: /usr/local/share/wayland-sessions, readable by SDDM.battery/low battery or ac power. That's because the sleep function doesn't work properly on FreeBSD. Sleep has been a problem under Xorg, as well, so I know it's NOT Wayland-related. You can turn off sleep by going to KDE's System Settings app -> Power Management.
I had this problem too, I solved it thank to AlfredoLlaquet who wrote a how-to:
I agree. I was reclutant to try the Wayland session, but had to say that things are going pretty well.
amdgpu driver!amdgpu driver - the PSR (Panel Self Refresh) bug.amdgpu firmware drivers operate.KWIN_DRM_NO_AMS=1
KWIN_DRM_NO_DIRECT_SCANOUT=1Setting them in your .profile should work, since various shells configuration files are sourced at login, but if you want something more "plasma-specific" create a file with .sh extension in $HOME/.config/plasma-workspace/env and export those variables there.
export GTK_USE_PORTAL=1export KWIN_DRM_NO_AMS=1 and export KWIN_DRM_NO_DIRECT_SCANOUT=1...Green Sardine AMD graphics. I do get SDDM there, the full KDE Plasma Wayland experience, but I can't leave it alone. Graphics stack still freezes, crashes, requiring a hard reboot.dimgrey_cavefish and yellow_carp ) works, and I can't start Plasma Wayland, either. But Wayfire works fine, and virtually all the KDE apps (Dolphin, Konsole, you name it) can be started within Wayfire. And I can leave Wayfire alone, and not worry about graphics stack crashing while I'm AFK, like asleep or at my $JOB.
pkg upgrade and broke my nvidia wayland setup.Following up on this proved fruitful.
amdgpu firmware. In concrete terms, this is probably why my Thinkbook (with Ryzen 7 5825U) keeps having graphics problems pretty much no matter what version of DRM-kmod I use (Tried 6.6, 6.1, and latest). page_flip_timeout bug. One proposed workaround to avoid race conditions is to have the amdgpu driver to check the hardware version and enforce a delay. amdgpu.ko (as supplied by graphics/drm-kmod) apparently already does the hardware checks (and loads the appropriate firmware), but apparently does NOT enforce a delay. And that's what's leading to the graphics crashes on the older hardware.llvmpipe to have a KDE Wayland session on FreeBSD on metal).
I wonder if I happen to workaround stuff like that indirectly by globally doing vblank_mode=0/etc (I need my mouse not slowed down by random GPU stuff, but cool if it also avoids vsync driver issues
)
export CLUTTER_PAINT=disable-dynamic-max-render-time
export CLUTTER_VBLANK=none
export vblank_mode=0
export MESA_VK_WSI_PRESENT_MODE=immediateLet's stick to the Plasma 6 Wayland on FreeBSD, and related showstoppers in the stack, instead of getting off-topic.
I thought everything was made of ports and dependencies. The x11/kde pkg-descr says it's Plasma. It depends on x11/plasma6-plasma... What's offtopic?
Sometimes, correctly understanding the dependency graph and specifying what should be a dependency and what should NOT be a dependency is in fact the important thing, the theme of the conversation. But this thread is about something else. Something else is the theme of this thread.
