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

OK, tried to see what the above is about... And to start: That's really appreciated!

But now for the hard work:

This does look like a FreeBSD-specific fix. The Ports system downloads tarballs directly from the upstream repos. Sometimes the ports tree itself contains those patches to be applied, sometimes the upstream project accepts them.
 
It looks like that patch leaks memory. However, even if you don't apply that patch, you can still set the KWIN_SCREENSHOT_NO_PERMISSION_CHECKS environment variable to 1 which will allow you to take any type of screenshot with spectacle without encountering authorization errors.
 
Yep, that's what testing looks like. Even if there's a quick-and-dirty solution that gets over the hump, it still may show that there's more work to be done in making sure we get the solution right.
 
Okay, I applied the patch https://bz-attachments.freebsd.org/attachment.cgi?id=252525 that had been attached to this bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280638 . After I did it, spectacle became fully functional in the plasma wayland environment. I am now able to take every single type of screenshot without encountering authorization errors.
The PR 280638 ticket proved to be the winner:
1733798842642.png

It did take using the patch that does not have the memory leak: attachment 255745
Now it's on to recompiling to address the right-click crash.
 
  • Like
Reactions: drr
I too get a fixed screen resolution of 1024x768 in wayland, with both plasma5-plasma and plasma6-plasma. Is there a way to enable other screen resolutions?; though i have not managed to go through all posts here, a forum search found only a handful of posts on screen resolution and I could not find a solution in them.
This is what I have... after compiling my way into KDE 6 Plasma Wayland from scratch, with all options turned on, and patched as mentioned in recent posts:
1733866208163.png

Once Spectacle started working properly, so did prt sc button on my keyboard...
 
astyle does this mean that plasma wayland in FreeBSD at the moment supports only a fixed set of standard screen resolutions? The monitor that I use has a not so common 16:10 screen ratio with 1920x1200 pixels.
 
astyle does this mean that plasma wayland in FreeBSD at the moment supports only a fixed set of standard screen resolutions? The monitor that I use has a not so common 16:10 screen ratio with 1920x1200 pixels.
I think that screen resolutions you see in the screenshot are more of a result of me using an Open Source driver for very old hardware. Basically, it's the GPU driver, rather than Plasma Wayland, that determines available screen resolutions. I haven't tried it, but I expect that an Xorg session of the same Plasma 6 desktop will produce the same results.
 
I haven't tried it, but I expect that an Xorg session of the same Plasma 6 desktop will produce the same results
For me, Xorg plasma session correctly produces all usable screen resolutions on the same machine and I have been using plasma5 x11 session on it for quite some time.

I tried plasma6 too once; Xorg session works fine and wayland is limited to 1024x768. With wayfire and sway, I am able to get the correct resolution of 1920x1200, using the same intel driver (drm-kmod).

Incidentally, I tried to run plasma6 wayland session on this machine with Void linux a couple of days ago and got the same limited screen resolution of 1024x768; so the issue I am facing does not seem to be FreeBSD-specific.
 
Frameworks updated from 6.7 to 6.9 in both kde-it_goes_to_6 and main repos. Dunno if that solved the issue of plasmashell crashing on right-click. One frustrating thing is that in the main repos, Plasma is at 6.2.3, but KDE Gear is still stuck at Unstable/24.01.90, while in the kde-it_goes_to_6 repo, KDE Gear is at 24.08.1, and very stable.
 
Frameworks updated from 6.7 to 6.9 in both kde-it_goes_to_6 and main repos. Dunno if that solved the issue of plasmashell crashing on right-click. One frustrating thing is that in the main repos, Plasma is at 6.2.3, but KDE Gear is still stuck at Unstable/24.01.90, while in the kde-it_goes_to_6 repo, KDE Gear is at 24.08.1, and very stable.
Kf6 never had any relevance to the right-click crash, so why would you think kf6 6.9 resolved the crash issue? As I said before, this resolves the right-click issue: CXXFLAGS+= -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 in /etc/make.conf. You will need to recompile both base and ports.
 
Well, after recompiling that same set of software on a Ryzen 5 7600 rig, and making use of the x11-wm/plasma6-kwin patch and the D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2 flag (oh, and patching the amdgpu driver as per instructions in the thread Thread amd-ryzen-9-7940hs-radeon-780m-graphics-now-working.92161) several times over, I came up with the results that are captured in the attached screenie.

Starting Wayland from a TTY - that was like banging my head against a wall. Sometimes commands work (but then the GPU shows up as llvmpipe) sometimes they don't. And when they don't, the errors range from complaints about /dev/drm/card0 to going into an unstoppable loop that can only be resolved by a hard reboot. I tired playing with those commands, rearranging them, trying to replicate what I pulled off on the HP Folio 13 laptop - to no avail. Edit: PR 282142 seems to be related to those issues...

The attached screenie shows what happens when I run ADG's waylad launcher script from within an Xorg session of KDE 6.

The aforementioned compilation flag did solve the right-click bug - but now the Wayland session cannot be reliably started (unlike Xorg). And Spectacle is behaving weird under the Xorg session now (and completely uncooperative in Wayland sessions).
 

Attachments

  • Screenshot_20241229_121203.png
    Screenshot_20241229_121203.png
    666.8 KB · Views: 119
I tried plasma6 too once; Xorg session works fine and wayland is limited to 1024x768.
The very fact that Wayland gives only one resolution (1024x768) suggests that:
  • It was launched from within an Xorg session, rather than bare metal TTY
  • The GPU that Wayland can see in that session is llvmpipe, rather than the proper hardware (like amdgpu) that Xorg can see.
 
Well, at this point:

Spectacle works freaking perfect! In both Xorg and Wayland sessions.
1735775146144.png


BUT....

Still cannot start a Wayland session from bare metal, not with

/usr/local/bin/ck-launch-session /usr/local/lib/libexec/plasma-dbus-run-session-if-needed /usr/local/bin/startplasma-wayland


or


/usr/local/bin/dbus-launch /usr/local/bin/ck-launch-session /usr/local/bin/startplasma-wayland


From within an Xorg session, the second choice works (and produced the screenie in this post), while the first one (gleaned from ADG's blog) leaves me with a black screen. and most likely goes to a vicious loop that is only possible to stop with a reboot.
 
  • Like
Reactions: drr
Well, wow. After solving the problems on the i915 driver, they are all cropping up again on the amdgpu driver. Same spectacle bug, same right-click bug, all reproduced on on the amdgpu driver after getting successfully solved on the i915 driver in this thread...

REALLY not looking forward to recompiling everything with the same flag in make.conf... takes 2 long days even with my Ryzen 5 7600.
 
what do you mean "Same spectacle bug"? did you install the version of plasma6-kwin that preceded this version: https://cgit.freebsd.org/ports/commit/?id=4a7cd62cf1060a85d463e45d7ff095c821848d4c ?
No, after. My snapshot is from March 6. The commit references Kwin v. 6.3.0. My version of Kwin is 6.3.2. At some point, I'll have to start keeping track of exact commits, not just dates.

But yeah, exact same Spectacle bug... at least the thread points to a patch and directions on how to apply it.
 
Well, damn.

The flag in /etc/make.conf (CXXFLAGS+= -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2) still works, right-clicking is safe.

But... Looking at commit logs at https://cgit.freebsd.org/ports/log/x11-wm/plasma6-kwin/ :
The ticket PR 280638 is marked as closed, but it's definitely not solved. Last two comments (#11 and #12) on that ticket indicate that the screenshot issue still persists. No idea why the ticket was closed.

One more complaint that I have on this topic, screen locking works, but I can't leave it alone under Wayland - something just crashes, and I'm left with a blank screen. I have to SSH in from the side and reboot.

I'm glad I can launch with amdgpu from bare metal, but this is still a very fragile setup.

BTW, XDG_RUNTIME_DIR environment variable really has to be /var/run/user/1001, and not /var/run/xdg/astyle. This is another inconsistency that I've been running into. The former variant allows me to consistently and successfully start from metal. Unfortunately, I've had times when /var/run/user/1001 was randomly replaced by /var/run/xdg/astyle or completely disappeared, and env variables did not persist across reboots. 😭

Also, when I shut down, I get error messages about Pipewire crashing. Haven't captured those, but I think they might be relevant.

So yeah, progress has been made, but there's still a lot of ducks to get in a row.
 
I don't know why other people would still encounter the problem with taking screenshots. Once the official fix was added to the ports tree, I no longer had to apply any special patches, etc.
 
I don't know why other people would still encounter the problem with taking screenshots. Once the official fix was added to the ports tree, I no longer had to apply any special patches, etc.
Could it be the difference between amdgpu and i915 GPU drivers? or PipeWire being still funky?
 
I have done a completely fresh install. I only installed my DRM Kmod for my AMD GPU, and --glob plasma6* and --glob kf6* with no x org specifically called out besides dependencies. The session works but the second I right click goes black screen never comes back.
 
I have done a completely fresh install. I only installed my DRM Kmod for my AMD GPU, and --glob plasma6* and --glob kf6* with no x org specifically called out besides dependencies. The session works but the second I right click goes black screen never comes back.
That's what the compilation flag is for - to make sure ^ this doesn't happen:
The flag in /etc/make.conf (CXXFLAGS+= -D_LIBCPP_TYPEINFO_COMPARISON_IMPLEMENTATION=2) still works, right-clicking is safe.
This thread does say that you gotta compile everything from ground up, kernel AND all the ports, using this flag. It takes me 2 days working nonstop with a Ryzen 5 7600, but that time includes downloading all the needed stuff and verifying that the graphics work fine in Xorg.

If you're curious, you can go a few pages back up this thread and reconstruct how the whole situation came up in the first place.

I don't think I have it in me at this point to spend the time figuring out how come Spectacle is still such a showstopper. What if I'm using just the wrong version of LLVM, and that somehow leads to problems that were not there earlier? When I used LLVM18, Spectacle worked fine - on i915... or maybe LLVM is not the issue? why? I don't have the skill to really answer a question like that. That's what debugging really is - it's not nearly as simple as "Debugging Bootcamp" people make it out to be.
 
Back
Top