Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have graciously supported us for almost 5 years, but all good things come to an end. We are expecting to transition to new infrastructure between late March and mid-April. We do not yet have a firm timeline for this, but it will involve (probably multiple) periods of downtime as we move our services whilst also changing them to be faster and more responsive. Any updates will be posted in freedesktop/freedesktop#2011 as it becomes clear, and any downtime will be announced with further broadcast messages.
Lima fails with white screen in master. 19.1 is ok
In sailfish on the pinephone, we are using lima 19.1.4 relatively successfully. However, when updating to a more recent version in a hope to fix various rendering issues, we hit a problem.
To simplify, I built kmscube to test the mesa install.
Running kmscube with master results in a white screen.
I bisected over about 8 hours (!) and found the culprit to be this commit:
mesa/mesa@cf1ab4b9
I double checked the previous commit which shows kmscube ok:
mesa/mesa@443c5a3c
Userspace is 32bit, and compiler is gcc version 4.9.4 20160726 (Mer 4.9.4-1) (Linaro GCC 4.9-2017.01)
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Well on my testing kmscube works with 32-bit userspace and 64-bit kernel on a recent distribution, so I think we can rule out a bug because of that. So I believe all you can do is try another distribution or gradually upgrade parts of the distribution you are using to find what is broken.
I tried this with a fedora 30 armv7hfp container. If you can't install another distribution on your platform, can you find a way to install docker on it and try it on a container?
I suggest to completely disregard the "offending" commit as it has been there for a long time, is completely unrelated to the issue and it is unlikely we can do anything about it.
The builds happen on the sailfish OBS build server, so each build is completely clean. Perhaps you could extract the binaries from an rpm to run in your environment?
Sorry at this point this is such a specific issue that I don't have so much interest in doing something like that. A general 32-bit on 64-bit bug would be interesting to lima but this seems like just an environment dependent thing we can't support. I'm afraid you will have to come up with a more standard environment to have something others can reproduce on their own on git master builds (regardless of 32-bit and 64-bit combination now).
Not much of an update. Neochapay has got mesa master working with mer, sailfish 'upstream'. He has the benefit of gcc8 and an aarch64 rootfs. Im still waiting for him to try his work on regular sailfish. A pinephone with sailfish would be the ideal environment, is that something youd be willing to try?
These logs and debug.zip are unfortunately not very helpful. kmscube works fine on master everywhere else. You still need to find the differences that matter between your platform and working platforms. For example master on another operating system where it works.
It is also strange that you need -D/dev/dri/card1. On a normal system that should not be needed. Try ensuring that sun4i-drm (or other display driver) loads before lima so it claims card0 and lima card1. Note that things like kmscube need to run on the display driver card node (which calls lima in the backend), not directly the lima node. This should make things easier for other applications too.
I'd try reproducing that myself on a pinephone but I don't have one.