I’m trying to get KDE/Plasma on my VF2 up and running. What I achieved so far is, that I’m able to start weston and from the terminal in weston launch “startplasma-wayland”. That then gives me a very slowly reacting plasma desktop but even that not in fullscreen but a small window (1/3 of the screen approximatly).
That is by far not the smooth experience compared to debian/gnome from the starfive image.
What I use is the archlinux image, kernel, kernel headers and kernel soft packages, @cwt kindly provided, the gpu driver he packaged and mesa-pwr-vf2 in version 22.1.3 (22.1.7 has no OpenGL support).
GPU firmware is loaded at boot after fixing some incompatible packages issues and I’m able to start weston and work in normal speed with the provided terminal or start Xorg and even start the “gears” demo using opengl there.
Starting Plasma X11 or Plasma Wayland from SDDM results in black screens with only the mouse cursor or even only a black screen with nothing at all (monitor backlights are on).
Most successfull as for now is to start “dbus-run-session startplasma-wayland” which gives a somewhat working desktop but in a weird resolution and the mouse pointer having stripe artifacts and moves in an even smaller rectangle only.
While loading, I can shortly see the background image in normal resolution and then the resolution (or scaling) changes as described.
If anybody has any hints where to look or what to try, I would really appreciate that.
Ok, dual boot up and running and working fine so far. Only drawback is, that for selecting your non-default OS (debian in my case) you need the USB2Serial adapter for selecting the secondary OS. But other than that, it works great.
Back to Plasma…I had a look at the pine64 stuff and am even more puzzled now. They use X11 with modesetting and that does not work at all for me. I get the default X screen but with no font visible and only white windows with a cursor. No possibility to type anything visible.
If I use X11 with the default .xinitrc, I can at least run “gears” or “konsole” e.g. to mention something from the KDE/Plasma realm. Debian seems to use wayland but that works not really well currently (except for weston with a simple console).
My best bet currently is, that the compiled packages for gpu-driver/mesa/X11/wayland are somewhat different between debian and arch and even for pine64. I’ll have a deeper look into the SDK and what they are doing there.
After having a deeper look at the SDK (buildroot/package/mesa3d), I found a mismatch that I was not able to resolve:
Last release tag is v3.7.5 and I’m looking here: GitHub - starfive-tech/VisionFive2, subrepo “buildroot”. Branch is JH7110_VisionFive2_devel
But when I dive into the buildroot/package/mesa3d directory and have a look into ‘mesa3.mk’, there is version 22.1.3 in use. But in my installed debian, it is 22.3.5. That is way newer but I can’t find any buildroot or other sources from which that was built.
Ok, partly success. I’m running KDE/plasma on X11 now. It is usable but glxgears e.g. does not work currently.
The way I achieved that is not that “pretty” as I would like to tho. I just fetched the debian packages and created an Archlinux package from that.
But again: if anybody could tell me, where to get the mesa sources, the starfive debian mesa is build of, I’ll be happy to create a PKGBUILD from that.
There is a xorg.conf under /use/local in the debian image that worked fine with the Arch image for x11 with drm. For weston the drm option also worked.
AFAIK all these are based on the kernel mode setting provided by the imgtech pvr kernel module. gst-play for example can directly render to kms without x11 or Wayland overhead. That got me almost smooth 4k playback at 4k@30 resolution.
cat /sys/kernel/debug/pvr/status
Has some GPU state infos
There is no full opengl only opengl es so for testing use egl* or esgl* tools.
Might be, that it has been that way at some point in time but the current debian image from august runs gnome-wayland-session and uses packages not available on debian ports (img-pvr-rogue e.g.) which contains things like libpvr_dri_support.so which are not available in the SDK. And, they are even using a different version (newer one), as I mentioned above.
GPU state in SysFS only tells you, that the kernel driver is working and that is the case as soon as firmware loading worked and the direct rendering driver is in the kernel.
But for Wayland/X11 to be working with that hardware driver, a suitable DRI-implementation is needed and that is currently missing. With the mesa-package available from @cwt, I don’t have any working X or wayland at all (well, X only in the default twm confguration but not with plasma/gnome. And that is working (as my current solution is) via framebuffer device.
The PVR modesetting driver used in debian is not working or at least I did not manage to get it working in Archlinux.
What I want to achieve is, that I have a working X/Wayland Plasma session with hardware acceleration just for the UI. Video/3D (as in games) is not of importance to me in the first place. And I want to be able to compile everything needed instead of just copying it together from binaries. (Binary blob firmware is kind of ok tho).
So, if you have got any information about a repository containing that exact mesa build information leading to the mesa packages used in debian, I would be very happy
What I have noticed is that openGLES works on Debian wayland, and debian Xorg, but not on Xwayland that is usefull with GL4ES that warp openGL with openGLES.
The Pine64 (specifically for Star64 and PineTabV) are using Wayland rather than X. It was simpler and easier to get the KDE/QT dependencies working there, but later releases of the IMG-Rouge driver in the StarFive kernel cause artifacting/corruption.
For a proper bare bones look at what’s was required to get Wayland with GPU acceleration look at the meta-riscv yocto recipe which the pine64 images build upon.
(There is X support in the pine64 images but it does not leverage the GPU acceleration).
I had a look at the receipes but could not find any mesa receipe? Is that correct?
I’m running mesa too here and SDDM+KDE is working on Wayland but using softpipe and beeing very, VERY slow. X is running too but with wrong colors.
Since I’m not really an expert in the inner workings of mesa, X, wayland and stuff, it’s kind of difficult for me, what is wrong here. Especially because the gnome installation on the official debian release seems to not support wayland-info to get a grasp on what really is currently beeing used by wayland, when it runs. Also journald does not come up with very helpful information.
Is there any tool which could help to identify where the software stack of the running UI differs? Something telling me, gnome on debian is using gnome-wayland-session on top of {insert mesa/libdrm/whatever here} and using /drv/drX?
Btw: things have gotten better after using the environment setting used here: Building Starfive Debian image
But it is still very slow and every UI interaction causes the cpu load to jump under the roof.
Any further hints or perhaps some IRC chat or other, more direct form of interaction so I could reach the same performance level as provided by the debian installation?
Of course I would provide the solution, settings, package builds or whatever is needed here and on my github.
(repost) For anyone that has weird color with the built-in HDMI output, I have appeared to fix it with this Xorg configuration file. Here it is running xfce4 with the correct blue mouse color. GitHub gist
Thank you for sharing! I can confirm, that that corrects the colors. X is even faster and near the speed of debian with gnome wayland but without working 3D.
So, the only thing missing is now having it work at least that way on wayland+sddm+kwin_wayland too.
My best success I get meanwhile with the debian packages, repacked as an Arch package.
but, as I mentioned, that is very slow. So now we need to figure out, what is now the diffence between debian and arch that prevents it from working the same way.
@Nightwulf Can you install mesa-utils run eglinfo in your debian image? This is my output and I’m attempting to switch driver on the arch image to swr for X11 to attempt some acceleration. Github Gist for eglinfo output
Hopefully as the team releases the new debian image, there would be improvements to X11 hardware acceleration and maybe reuse it in the arch image as well.
After some digging, I have discovered that the Debian image is in fact running gnome-shell window manager and mutter on X11, and not wayland.
I have been running LXQT on my arch image, which uses openbox window manager by default, it is extremely slow when it comes to moving windows. I have tried serval other ones such as icewm which does seem to help with performance of moving windows around. However, I’m not sure if these window managers have access to any hardware acceleration. Maybe I will try compiz as it supports OpenGL acceleration.
I can’t seem to get any OpenGL/EGL application such as eglgears_x11 to work with X11, even with the pvr mesa driver. I have not tried zink yet. Maybe just the driver needs to be updated.
When you mentioned that it is “slow”, what do you mean by “slow”?
Could it just be kwin being the cause of the slowness?
Acceleration (3D !) is not the problem. Gears is running on both, Arch and Debian and also with comparable speeds. (I’m using the last release 3.7.5 btw).
I attached four info files with egl and wayland infos for both, debian and arch.
