Haha we all do miscellaneous work.
2 Likes
On the other hand, did you check that lima was actually used ?
The X server logs seems to indicate that the ~/launcher/.xorg_lima.conf was never actually loaded (not found, using default conf fallback), glxinfo always indicate that either llvmpipe or softpipe are in use to provide the rendering, and kmscube won’t even work. Might be a faulty libdrm or sun4i*.so on my side, but it’s best to be sure.
Anyway, @guu compile options were also what I ended up with during my tests, except for the osmesa flag that I did not set since lima should support it.
Also, since compiling mesa is quite long, I noticed that someone provides prebuilt debs for debian buster (current stable) armhf, exactly for this purpose (enabling lima in stable). Here is the repository :
https://github.com/zhangn1985/lima_gpu_drv
His compile flag also include the necessary stuff (kmsr, swrast, lima, surfaceless, x11, drm) plus a few other things we absolutely don’t need. They seem based on the official debian build flags
EDIT:
Got it to work ! kind of hacky for now, will write instruction when more reliable.
This makes undertale playable using box86 ! (well, at least throught the ruins, and with a few graphical issues …).
That was my output.
Also, a lot of things, like XMB menu items that previously were glitchy in retroarch are now properly rendered. Mupen64 emulation of say, mario kart no longer has black boxes around “sprites”, and general performance/stability seems WAY higher! I haven’t test much else that is Lima dependent.
Also, holy cow! I would love to see how Undertale works! That’s amazing! 
1 Like
The two commands you ran actually show that the lima driver is loaded properly, not that it is currently used. However, it do seem that it is given the performance you are getting.
In order to check, you can run glxinfo, which should show you mesa/lima in the vendor string. Otherwise, it will display llvmpipe or softpipe.
If it does, and glxgearsdisplay error messages such as operation not permitted, please run
sudo usermod -aG render cpi and reboot. It will add you to the render group, and give you the proper permissions to use render devices, such as /dev/dri/renderD128 which is visibly our card’s little name in some cases.
Undertale pics :
3 Likes
Here’s a quick update - Just the last 191114 image, with the latest lima drivers applied.
It runs like an absolute beauty! @Wizz, if you could host this for people who find my link too slow, that would be great!
I haven’t applied guu’s auto expander, or zeroed the empty space - that’s a tonight job. But I thought I’d upload this for now, just so people can test it out before making the official “final” version.
There is one bug that I’ll have to iron out. Seemingly, switching to the stock launcher hangs. I’ll have to investigate further. For now, just stick to using the DEOT launcher.
@guu or anyone else with time - Would it be possible to have someone upload a version with guu’s empty space zeroing and auto expander script applied? I’m only using a linux virtual machine, with a 20GB partition, and with my expanded image being 16GB, it’s going to be a huge pain to put together. No worries if you can’t - I’ll get it done eventually.
ok, wait for me about 6 hours
it seems dropbox is slower than google driver
1 Like
I 'm wondering why mesa load driver file sun4i_drm_dri.so instead of lima_dri.so.
I checked the clockwork pi dts file and found that it includes “sun8i-a23-a33.dtsi”,according to the driver which mesa loaded,mesa considers it is sun4i.
but “sun4i-a10.dtsi” which I found in kernel source code has quite different defines of mali 400 GPU,here it is:
It would be nice to have you reply,thanks.
I am not very sure ,too
seems that the lima_dri.so is only useful when get into 3d jobs
sun4i_drm_dri.so is for other situation
I think sun4i_drm has nothing to do with dts file, the drm in the kernel told xorg to look for the sun4i_drm_dri.so
that is my guess
That’s odd. when I run mupen64plus to play zelda ,lima_dri.so seems not be loaded either.
I tested with
lsof |grep lima_dri
may be I need to rebuild mupen64plus
how is the cpu usage when you run mupen64plus to play zelda anyway?
htop shows the cpu usage is about 50%,and some time the game just crash.
Is this using my image where I’ve built mupen?
The one I use has seen changes, ie no more black box problems, but definitely running at the speed of the Lima drivers, and faster.
@guu I’ve uploaded it to my google drive too. It’s the one from the original post.
No,I am now downloading the latest image you have built.This will take a long time,because I need to use a proxy for the downloading from google drive.
1 Like
Cool, downloading it now and will post a link after uploading it to my environment 
AAAAAAAND DONE;
https://pcroz.stackstorage.com/s/a26iBYxvkQ5VSgS
I have restricted to download only, but can also activate the upload function. Over the next few weeks I will move it to a private, non commercial service and increase the speed further. Currently upload/download took me about 30 mins but milage may vary based on your provider speed. If wanted, I can also mirror other images for the community.
1 Like
Holy moly!!! You have this kind of power??? I … am impressed!
@guu will possibly be uploading an edited one with a smaller size and resize script. I’ve also gotta upload more icons and fix the launcher switcher. But besides that, this is basically the final version, until clockwork OS 0.5 comes out. Judging by the headway made in this thread, I’m guessing it’s around the corner 
I think I watched He-Man once too many when i was younger and am taking the "I have the Power’ a bit to literally. ;-). Will host newer versions when they are posted !
1 Like
https://mega.nz/#!9AliFIJa!QTTiI_VCPiD009DcqMAPGUHhVcI6BW_WqNVZkyMuVPM
so here it is
deot_v1+ 191122.img.tar.bz2
smaller size , auto expand rootfs
3 Likes
您好，请问可以分享一下，新的lima驱动再o.4系统上的安装方法吗，因为我安装的系统有大量的设置，所以暂时没有换系统的打算，谢谢。