When you mentioned that it is “slow”, what do you mean by “slow”?
Could it just be kwin being the cause of the slowness?
Tbh…I don’t know what is causing it. Dragging windows around stutters, clicking on the KDE menu button takes 5s until the menu pops up etc.
Even the colors…e.g. in the CPU utilization widget, the bars should be in different colors. But they are not. Xwininfo tells me, I’m on 24bit color depth. But they are all white. And displaying that widget takes 100% on one core all the time. That tells me, that some parts of UI acceleration do NOT work. I don’t expect speeds as on my desktop PC but comparable to debian Gnome.
Then, there are currently issues with the Archlinux package repositories because some dependencies are wrong (powerdevil has wrong ddcutils e.g.).
Monitor settings dialog shows me an error, that no kscreen backend runs and so on, and so on.
So…in conclusion there are so many different things looking somewhat strange, that I currently have no real clue, whether it is really one problem or several and which causes what glitch.
Oh, btw…both installations running from NVME SSD.
What I’m currently in need of is some starting point to sort things out.
Under wayland…in X11, no version works (glxgears,gears,eglgears_x11). But also that is highly dependent on which mesa-package I use.
mesa-pvr-vf2-22.1.3 (cwt) → Wayland working as I described above
mesa-pvr-vf2-22.1.7 /cwt) → basic X works but no plasma, neither on x11 nor wayland
mesa-nw-vf2 (me) → this package is basically the binaries from debian 3.7.5 release packed into an arch package…works comparably to 1,
For the cases where plasma works on X11, this variant shows faster UI experience than with working mesa.
I’ll give the new version a try on SD-Card at first to look whether the effort is worth it for me.
Other than that, I try to get buildroot environment to build on my PC to have a “positive” for creating a similar arch package. Currently it stops while building the firmware image because hashes don’t match.
News with a small success…at least not for Archlinux + Plasma but for Archlinux + Gnome.
It came to my mind, that there are two devices for the gpu in the dev filesystem. /dev/dri/card0 and /dev/dri/card1. In the journals I was able to see, that kwin_wayland tries to use /dev/dri/card0 at first, getting not the needed features from it and is falling back to a legacy mode then, using /dev/dri/card1 @leon3321 then tried to force wayland to use that device and for gnome that is simply made by creating a udev file containing the following rule:
For Gnome with Mutter the experience is then comparable to the debian one.
For kwin_wayland I did not manage to find an environment variable, switch or udev rule doing the same. So if anybody knows a solution to that, it would be great.
You should put this in /etc/environment just like the debian image.
This is only a workaround, because setting QT_WAYLAND_CLIENT_BUFFER_INTEGRATION to some random value speeds up the DE.
There are some issues:
Many applications that depends on plasma is still very slow, such as console or the file manager, they appear to still use software rendering, and may crash the desktop.
Installing foot, the terminal emulator does allow me to have a working terminal emulator, which I can run programs with. I recommend doing this instead of using other emulators.
There is also a weird bug where if I log out of a desktop session, I can not log in again due to Kwin not being able to lease the card1 device, a full power cycle does seem to resolve this issue.
We’re not totally there tho…kinfocenter doesn’t run at all, crashes while trying to load that “test1” buffer integration…some Widgets down’t draw their content correctly…and restart via menu doesn’t work correctly…but we are on a good path!
Result gets even better (kinfocenter works again) with dmabuf compositor: linux-dmabuf-unstable-v1
so use QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=linux-dmabuf-unstable-v1
I have a new mesa-pvr-vf2 with updated build flags that I tested working with plasma-wayland. Graphical acceleration for opengles2 games (PPSSPP for instance) seems slower in KDE than it is in weston. But both are working. mesa-pvr-vf2-22.1.7-2-riscv64.pkg.tar.zst (4.3 MB)
Tested the new package and found not much of a noticeable difference. gears is running slightly faster (28fps → 32fps) and webgl demo “Aquarium” rendering to full extend now but continues to be at 0fps (updating every vew seconds).
I repeated the successful plasma wayland desktop/firefox install with sddm after ensuring the two files /etc/environment and /etc/sddm.conf.d/10-wayland.conf have been modified as mentioned above. If you install gnome and gnome-extra afterwards, you get screen tear/jaggedy display scanlines and make it unreadable, but logging out and logging into plasma wayland afterwards the sound works perfectly with volume control and all. I can validate the sound quality and volume work well through the latest firefox on youtube videos.
@cwt and @Nightwulf are super-heros. If I forgot to give credit where credit is due please remind me. Thank you all. Cheers. I find the mouse behaviour and the display of menus and the invocation of apps quite snappy in kde. The gnome desktop felt it was going to be snappy as well if it wasn’t for the jaggedy scanlines making it hard to use.
Thank you very much! But don’t forget @leon3321 who gave a very important hint regarding the /etc/environment file!
Btw: when talking about Gnome…did you install gdm and mutter? These are the pendants to sddm and kwin for gnome. Without them it won’t work.
The list in sddm is just longer that’s all. Rather than selecting plasma wayland at the sddm login, you select gnome wayland, then type in the password and press enter. The gnome desktop did display, but as I stated, it was jagged scanlines and I could hardly read anything. It was as snappy as kde though. I’m certain mutter also installed automatically. otherwise I wouldn’t have been able to see the gnome desktop either. The activities button was working in gnome by the way, but difficult to see the windows/icons/workspaces layed out…the jagged scanlines as stated before make it unlegible.
What I fail to understand if both kde and gnome depend on wayland, why is it that kde displays the desktop correctly with no issues scanline-wise? I would figure at that level, they would be using the same apis.
Because they are using different compositors (mutter for gnome and kwin_wayland for KDE/Plasma). And that’s why I’m unsure whether using SDDM works at this stage for starting GNOME because they are doing some things differently when it comes to configuration. But I’m not a gnome expert so I don’t know for sure.
