Hello Guys,
Can I ask you somes question on kernel 5.3.6 and lima driver ?
I have update the kernel of my gs to 5.3.6, but I’m not sure if I understand well, prefer to ask some help to avoid any mistake.
After the kernel update, do I need other thing to run as well as possible Lima ?
I’ve you test an solution to not break the shell with apt after updating the mesa ?
Thanks lot
1 Like
Of course I’ll post it soon 
1 Like
I know that. But what else should break lima when using the driver switch? Look at the code of the driver switch. Why would it rename modesetting_drm.so to modesetting_drm.so.lima when switching to fbturbo if the (fbdturbo) xorg.conf doesn’t use modesetting? .Also apt upgrade will overwrite this file when upgrading xserver-xorg-core.
I’m not a newbie when it comes to linux but I’m still trying to wrap my head around all of the ARM stuff.
As far as I can see the image does the following when booting:
getty executing
/etc/systemd/system/getty@tty1.service.d/autologin.conf
[Service]
ExecStart=
ExecStart=-/bin/autologin.sh %I
which executes
/bin/autologin.sh
if [ -f /tmp/autologin ]
then
exec /sbin/agetty --autologin cpi --noclear $1
else
exec /sbin/agetty --noclear $1
fi
which automatically logs in the user “cpi”, automatically executing:
~/.profile
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
# see /usr/share/doc/bash/examples/startup-files for examples.
# the files are located in the bash-doc package.
# the default umask is set in /etc/profile; for setting the umask
# for ssh logins, install and configure the libpam-umask package.
#umask 022
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
which executes:
~/.bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
# If set, the pattern "**" used in a pathname expansion context will
# match all files and zero or more directories and subdirectories.
#shopt -s globstar
# make less more friendly for non-text input files, see lesspipe(1)
#[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "${debian_chroot:-}" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color|*-256color) color_prompt=yes;;
esac
# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
fi
unset color_prompt force_color_prompt
# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
;;
*)
;;
esac
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
#alias grep='grep --color=auto'
#alias fgrep='fgrep --color=auto'
#alias egrep='egrep --color=auto'
fi
# colored GCC warnings and errors
#export GCC_COLORS='error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
# some more ls aliases
#alias ll='ls -l'
#alias la='ls -A'
#alias l='ls -CF'
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi
fi
if [ -f ~/launcher/.cpirc ]; then
. ~/launcher/.cpirc
fi
which checks if the OS is running in chroot or on the gameshell. if its running on the gameshell, it executes:
~/launcher/.cpirc
SCREEN=`cat /sys/class/graphics/fb0/modes`
XORG_CONF="~/launcher/.xorg.conf"
if [ -f /home/cpi/.lima ]
then
XORG_CONF="~/launcher/.xorg_lima.conf"
fi
if [ -f /tmp/autologin ]
then
rm -f /tmp/autologin
mpd ~/.mpd.conf
if [[ $SCREEN =~ .*320.* ]]
then
while :
do
startx /home/cpi/launcher/.xinitrc -- -xf86config $XORG_CONF -nocursor > /tmp/x.log 2>&1
sleep 1
done
else
while :
do
startx /home/cpi/launcher/.xinitrc hdmi -- -xf86config $XORG_CONF > /tmp/x.log 2>&1
sleep 1
done
fi
fi
which checks if whether lima is switched on or not, (e.g. checking if ~/.lima has been created by the script that moves modesetting_drm.so.lima to modesetting.so) and whether to use hdmi or the internal screen by getting the screen size and checking if the width of the output is 320 pixels. (which is kinda weird but works i guess) If that is the case it runs startx with following init file and xorg.conf:
~/launcher/.xinitrc
case $session in
hdmi )
feh --bg-center ~/launcher/sys.py/gameshell/wallpaper/desktopbg.jpg
exec ~/launcher/load.sh &
exec ~/launcher/sys.py/gsnotify/gsnotify-arm daemon &
#exec /usr/bin/twm -f ~/launcher/.twmrc
exec ~/launcher/dwm-mod
;;
gameshell )
feh --bg-center ~/launcher/sys.py/gameshell/wallpaper/loading.png
exec ~/launcher/load.sh &
exec ~/launcher/sys.py/gsnotify/gsnotify-arm &
#exec awesome -c ~/launcher/awesome/rc.lua
exec ~/launcher/dwm-mod -w
;;
*)
exec $1;;
esac
~/launcher/.xorg_lima.conf
Section "Device"
Identifier "Allwinner A10/A13 FBDEV"
Driver "modesetting"
Option "fbdev" "/dev/fb0"
Option "SwapbuffersWait" "true"
EndSection
They execute the launcher using the “modesetting” driver which uses the mesa-lima driver by default(?)
So we build libdrm 2.4.100 and mesa-git, install the libraries into the os move some “lima” files
to “lima.old” switch to lima and the “modesetting” driver just automaticly uses the kernel implementation?
If so, why should the builtin lima-driver-switch break that setup? it just moves the modesetting_drm.so file, removes the .lima file and changes a line in 00-arm-linux-gnueabihf.conf.
so using the switch to go back to lima should still work. Everything the application has changed, is changed back.
Even weirder: it’s not only lima breaking - FBturbo breaks too:
When you run:
DISPLAY=:0 glxinfo | head -n60
it should output a log with something like
driver: lima
(when running lima)
or
driver: llvmpipe 0.X
(when running fbturbo)
but when you run it after switching the driver, it will close with an error.
In this state retroarch will be unbearably slow (much slower than with fbdev or fbturbo)
The same seems to happen when using “apt install package” or “apt upgrade”.
Interestingly, changing the /etc/apt/sources.list entries from stable to sid (unstable) and upgrading will still break lima but not break FBTurbo. Maybe thats because of sid coming with mesa-19.2?
Like I said it was just a theory. I’m basically grasping at thin air here trying to find the cause for these problems.
I know apt upgrading isn’t that important for this kind of image but installing apps, libs and dependencies through is pretty useful and preferable to manually statisfying deps, compiling and configuring everything.
2 Likes
That’s seemingly the problem re: using apt breaking the Lima. At this stage, this image is a proof of concept with instruction hopefully lined up so anyone can try it themselves, or just download a precompiled build.
If you downloaded the build from this thread, you shouldn’t need to upgrade the kernel or drivers.
If you’re doing it to your own image, then you should be fine with what you’ve done, following the steps above.
Don’t do an apt upgrade until the discussions currently going forward have come to a concensual conclusion. That’s what’s hopefully going to be resolved.
Does this still happen when using apt on a stock 0.4 image?
The 191111 build is still being hosted in one of the links in the first post, and is a 0.4 image before having the Lima drivers upgrades. I believe it has the 5.3.6 kernel still.
Just wanting to find out whether or not it’s just something fishy with my customised build, or something in general that needs to be addressed. As stated above, I ran into similar problems months ago trying to upgrade to buster.
I would really like to see this image be far more bulletproof and developer friendly, so having the ability to use apt would be very much needed! Even if it’s a bigger issue in the vanilla 0.4 release and earlier, it would be really REALLY nice to have it resolved in an image as a community effort.
yes you are right
To force the x to use fbdev(fbturbo) , modesetting_drm.so must get away
that’s why I renamed the modesetting_drm.so
and others I am not sure now, after the recently launcher development, I will dig into that
and don’t get me wrong, you are absolutely not a linux newbie
2 Likes
I’m in the process of building everything using apt, just to see what happens on my end.
I’m currently using the 191111build, that is available in the original post in this thread. The only difference is, the lima/mesa files haven’t been updated. It’s still using the 5.3.6 kernel. (oh, also, it doesn’t have stray roms oops)
I did an apt upgrade (not dist-upgrade or full-upgrade) on the system, updating it to Debian 9 Buster. The only modifications after this were to the mdp.conf, getting rid of unused tokens. This shouldn’t affect any of the *.deb files. A few of the *.debs you used are applicable to debian 9. Perhaps this could be where some of the compatibiity/breaking occurred? There were a few instances where the included dependencies were newer than the ones I was installing. Eg.
The following packages have unmet dependencies:
libsdl2-2.0-0 : Depends: libc6 (>= 2.29) but 2.28-10 is to be installedAll in all there were a lot of downgrades. I’ll do an apt upgrade afterwards, just to correct anything that may have broken in the process, then finally apply the upgraded lima drivers. In fact, there were so many broken things that had to have a whole bunch of dependencies corrected etc that I’d be surprised if anything worked with my current setup.
One thing I noticed when installing the first *.deb is that it asks to remove a fair chunk of files. I haven’t looked through the list extensively (my eyes are VERY tired lol) but I’ve taken a screen cap, in case anyone else wants to peruse the output. I have pasted a log if anyone wants to comb through it. Note: This was just a second parsing, just to show the error messages.
I’ve uploaded all of the individual *.deb files onto my dropbox, in case anyone else wants to test out to see what happens after installing them, ie whether or not it breaks their installation. In particular, people who might have a different build, with or without the updates applied.
I’ll have an upload ready of the above for people to test out. I’m going to have to spend an evening going through my storage to find my Quake 1 installation discs, so I won’t be able to test it myself for a while. But I will report back as to whether or not Lima is broken or not.
Edit: Can that. Just did a test run of Banjo Kazooie. It was running BAD! Going to spend some time tonight/tomorrow trying to do the above again, this time not upgrading to Buster. That could have potentially been the cause? Either way, I’ll be using the 191111 build. I’m not going to bother uploading what I just did, since well; It is bad! Nevertheless, the files are here for other people to try.
I’ll keep trying to do literally anything else.
1 Like
I tried to get the official 0.4 firmware running debian Sid with mesa 19.2 and also with Debian Buster and even though they don’t use the kernel version of Lima, the problems I encountered are the same as with your custom deot 191122 image. On buster the driver switch breaks completely and it falls back to non accelerated rendering (so performance is abyssmal even with something like nes emulation).
And on SID with kernel 5.3.6 added, it loads the lima kernel module but uses software rendering through llvmpipe, so it is much faster than on buster (using the cpu for acceleration) but not nearly as fast as lima.
I’m still trying to find out why it is behaving like that but the xorg logs don’t show any interesting information and dmesg says lima is loaded. The best way of finding out what driver is working and which renderer is loaded was installing inxi and using “inxi -G --display” to get a Human readable output like this:
cpi@clockworkpi:~$ inxi -G --display
Graphics: Device-1: sun8i-a23-mali driver: lima v: kernel
Device-2: sun8i-a33-display-frontend driver: sun4i_frontend v: N/A
Device-3: sun8i-a33-display-backend driver: sun4i_backend v: N/A
Device-4: sun8i-a33-display-engine driver: sun4i_drm v: N/A
Display: server: X.Org 1.20.6 driver: sun4i_drm resolution: 320x240~N/A
OpenGL: renderer: llvmpipe (LLVM 9.0 128 bits) v: 3.3 Mesa 19.2.6
the " Device-1: sun8i-a23-mali driver: lima v: kernel" line shows that the mali gpu was recognized and the lima kernel driver is loaded
The "OpenGL: renderer: llvmpipe (LLVM 9.0 128 bits) v: 3.3 Mesa 19.2.6 " line shows that it is using llvmpipe which means even though it recognizes the mali gpu and loads its driver, it’s still not using the mali chip for rendering.
UPDATE: I got 0.4 updated to Debian 10 Buster, And got Hardware Acceleration through Lima running without apt breaking it.
It took a bit more work than the implementation before.
I’ll upload the Image and I’m gonna make a writeup of all the things that I’ve done to the OS make it work tomorrow (It’s 5AM and I really need to hit the hay).
It involved adding Custom Mesa and Xorg apt-repositories that I think someone posted here before, Adding/Changing Xorg.conf files, softdep some drivers to lima and compiling and adding the 5.3.6 Kernel.
Inxi -G output:
cpi@clockworkpi:~$ inxi -G --display
Graphics: Device-1: sun8i-a23-mali driver: lima v: kernel
Device-2: sun8i-a33-display-frontend driver: sun4i_frontend v: N/A
Device-3: sun8i-a33-display-backend driver: sun4i_backend v: N/A
Device-4: sun8i-a33-display-engine driver: sun4i_drm v: N/A
Display: tty server: X.Org 1.20.6 driver: sun4i_drm resolution: 320x240~60Hz
OpenGL: renderer: Mali400 v: 2.1 Mesa 20.0.0-devel (git-07d8b98b54)
3 Likes
You absolute champion!!
I’ll apply the custom apt repository and fixed acceleration with buster as soon as possible! Ugh I know what you mean re: tired late nights. (Australian heat wave 42 deg celcius days ugh)
By all means, feel free to use my image if you want. But also I’ll take no offense if you want to take a stock image.
I’ll likely modify the 191111 build with your updates
I prefer the your deot version, I just already had the 0.4 version installed on that card and I didn’t want to download the deot 191111 image. Applying this to the deot 191111 image shouldn’t be a problem. You could also just replace the cpi folder from the image with the deot191122 cpi folder to get a working version ( I guess the bootup screen would be wrong but everything else should work.) as I didn’t do any significant modifications to the launcher files. (it uses original .xorg_lima.conf together with another config at /etc/X11/xorg.conf.d/02_lima.conf)
Here is the Image:
Took me a bit longer because it was 64GB and pishrink.sh wouldn’t work on it so i had to manually shrink the root partition and use truncate to manually shave the image to a size of roughly 8GB. I used LZMA2 instead of Gzip for compression so I could get the image size down to 2.5GB. It will take longer to unpack but as people here where complaining about their internet connection I thought longer unpack times were preferable to a ~5GB download. It also doesn’t include an expand script yet so just get that yourself or use GParted. You can unpack it with unxz cpibusterpoc.img , xz --decompress cpibusterpoc.img on Linux or using 7zip on windows.
Also this image is hosted on my private server located in Europe so download speeds may vary. Feel free to mirror this file guys.
What does work:
- hardware acceleration using lima kernel driver
- Using apt to upgrade or install packages
- Using the builtin driver switch to switch between llvmpipe(fbturbo) and Mali400(lima) renderer
- Retroarch, Quake and all preinstalled indiegames
- glxgears with vsync through lima
What does not work:
- Mupen64 did crash when trying to start through the launcher but it runs fine when using this command through ssh (no clue why maybe recompile a new version?):
$DISPLAY=:0 /home/cpi/apps/emulators/mupen64plus --gfx mupen64plus-video-rice --fullscreen /home/cpi/games/mupen64/rom.z64 - when Bullseye becomes stable, apt might break it again (replacing all instances of “stable” with “buster” in /etc/apt/sources.list will prevent that)
- MPD daemon is broken and will throw errors at boot (this is because of buster, not my lima modifications. the conf file seems to use deprecated commands- shouldn’t be to hard to fix)
What I have done to make this work:
(I tried this with d.e.o.t 191111 and it doesn’t quite work as glamor defaults back to llvmpipe. I’ll check if I forgot something and update the post)
-
Replace the existing Kernel with @shell’s 5.3.6 Kernel uImage
-
run:
sudo apt update && sudo apt upgrade
(when asked for config overwrites check diff when in doubt keep old conf file) -
follow the instructions to add xorg and mesa repos:
-
do
sudo apt update && sudo apt upgradeagain -
get the sourcecode zip from @shell’s 5.3.6 kernel and do the following:
(assuming you have the clockwork-pi-linux-5.3.6.zip in your cpi home folder)
sudo apt install flex
unzip clockwork-pi-linux-5.3.6.zip
cd linux-5.3.6
cp ./arch/arm/configs/clockworkpi_cpi3_defconfig .config
make -j4 menuconfig
##save and exit without changing anything
make -j4
make -j4 modules
sudo make install_modules
sudo make install
- create lima xorg conf by doing this:
sudo mkdir /etc/X11/xorg.conf.d/
sudo nano /etc/X11/xorg.conf.d/02-lima.conf
Insert the following and save the file(by pressing ctrl+x and typing y):
Section "ServerFlags"
Option "AutoAddGPU" "off"
Option "Debug" "dmabuf_capable"
EndSection
Section "OutputClass"
Identifier "Lima"
MatchDriver "sun4i-drm"
Driver "modesetting"
Option "PrimaryGPU" "true"
EndSection
- make sure the sun4i* modules are loaded before lima by doing this:
sudo nano /etc/modprobe.d/lima.conf
Insert the following and save the file(by pressing ctrl+x and typing y):
softdep lima pre: sun4i_drm sun4i_drm_hdmi sun4i_frontend sun4i_tcon sun8i_tcon_top sun4i_backend
- (might work without libdrm but make sure to mv the files)do the following things from @guu’s instructions:
## install the new libdrm
wget https://dri.freedesktop.org/libdrm/libdrm-2.4.100.tar.bz2
tar jxvf libdrm-2.4.100.tar.bz2
cd libdrm-2.4.100
./configure --libdir=/usr/lib/arm-linux-gnueabihf
make
sudo make install
cd
sudo mv /usr/lib/dri/sun4i_drm_dri.so /usr/lib/dri/sun4i_drm_dri.so.old
sudo mv /usr/lib/dri/sun4i-drm_dri.so /usr/lib/dri/sun4i_drm_dri.so
sudo mv /usr/lib/lima /usr/lib/lima.old/
- use the Driverswitch to switch to lima and check if it worked using
inxi -G --display
(make sure you’re logged into cpi and NOT root)
if the output looks like this:
Graphics: Device-1: sun8i-a23-mali driver: lima v: kernel
Device-2: sun8i-a33-display-frontend driver: sun4i_frontend v: N/A
Device-3: sun8i-a33-display-backend driver: sun4i_backend v: N/A
Device-4: sun8i-a33-display-engine driver: sun4i_drm v: N/A
Display: tty server: X.Org 1.20.6 driver: sun4i_drm resolution: 320x240~60Hz
OpenGL: renderer: Mali400 v: 2.1 Mesa 20.0.0-devel (git-07d8b98b54)
It worked. else try
modprobe lima
and
modprobe sun4i_drm
and check again.
also check if the inxi shows Xorg version 1.20.6 and mesa 20.0.0-devel
I might try this out again with the deot 191111 image. If this doesn’t work right at all I might’ve forgot something but I think this was all I did. It was necessary to reboot a couple of times and modprobe lima until it starts working but after that it worked perfectly.
5 Likes
Wow It is a great post! I learned a lot
Will try your img later
Thanks for that
1 Like
HOLY COW THIS IS PERFECT! The fact that you’ve gone to the trouble to explain exactly how and why things are done - this is how communication and progress is made! Thank you so much!
Is it okay for me to provide your image on the download lists for this image; since it’s based on the custom image anyway? I love your work, and will certainly be applying it as a standard!
The 191111 image would just be a cleaner slate to work from, since none of the Lima/Mesa changes have been made; just to rule out any other potential problems that can occur.
Re: MPD deprecation, here’s the modification I made to mpd.conf. Nothing fancy; just commenting out deprecated Unicode sets, and disabling tidal and qobuz and all associated tokens. I doubt the CPI would be able to output adequate audio to really leverage Tidal anyway.
music_directory "/home/cpi/music"
playlist_directory "/home/cpi/.mpd/playlists"
db_file "/home/cpi/.mpd/tag_cache"
log_file "/home/cpi/.mpd/mpd.log"
pid_file "/home/cpi/.mpd/pid"
state_file "/home/cpi/.mpd/state"
sticker_file "/home/cpi/.mpd/sticker.sql"
user "cpi"
bind_to_address "/tmp/mpd.socket"
auto_update "yes"
auto_update_depth "2"
input {
plugin "curl"
}
audio_output {
type "alsa"
name "ALSA Device"
}
audio_output {
type "fifo"
name "my_fifo"
path "/tmp/mpd.fifo"
format "44100:16:2"
}
filesystem_charset "UTF-8"
# id3v1_encoding "UTF-8"
# QOBUZ input plugin
input {
enabled "no"
plugin "qobuz"
# app_id "ID"
# app_secret "SECRET"
# username "USERNAME"
# password "PASSWORD"
# format_id "N"
}
# TIDAL input plugin
input {
enabled "no"
plugin "tidal"
# token "TOKEN"
# username "USERNAME"
# password "PASSWORD"
# audioquality "Q"
}
# Decoder #####################################################################
#
decoder {
plugin "hybrid_dsd"
enabled "no"
# gapless "no"
}As for recompiling mupen, I’ve actually left the dependencies in the home directory under ~/.mupen. There a script to install them in the home directory called mupen.sh.That should be all you need to get mupen working, besides maybe fiddling with the config file and/or action file; specifically specifying which output to use. I think that was a problem people had early on in the mupen/gameshell days.
well , the download speed is pretty slow to me, hope someone can mirror this img to mega.nz
lol
1 Like
yeah but as I already wrote I’m missing something. I applied the modifications to the 191111 image but it’s still using llvmpipe the xorg.logs in /home/cpi/.local/share/xorg/ are telling me that while the lima driver is working, the xserver won’t leverage the hardware acceleration. I think the sun4i-drm driver is the culprit. So this writeup isn’t quite correct - but it is very close. probably something wrong with the dri files. when push comes to shove I have to flash my image again and compare the files in /usr/lib/dri/ to the one in the deot 191111 image.
Yeah like I said this is on top of a little vserver I rented located in europe so download speeds vary .
1 Like
are you sure about the need of /etc/modprobe.d/lima.conf ?
it work on my system without this
also for future updates i do ln -s sun4i-drm_dri.so sun4i_drm_dri.so instead rename
lima work pretty fine! 890fps on vblank_mode=0 glxgears
1 Like
It might be unecessary. this was just what I did. As I said I couldn’t reproduce this and most of the things I did in the writeup. they are just snippets of fixes for other devices using lima I used because after a couple of hours I kinda got desperate to find anything.
If it works for you, thats great,
Did you use the 0.4 Image or the deot191111 image?
Maybe there are some changes in that image that make it not work. The only way I could get the deot image running lima in the end was copying the /usr/ , /etc/ and /lib/ directories into the image.
(which means something has to be different but can’t figure it out 
)
It works now only problem is that retroarch segfaults but you can always compile a working version.
1 Like
mesa include sun4i-drm driver, your issue may come from using another one ?
i compiled mesa from source using :
git clone Mesa / mesa · GitLab --depth 1
meson setup mesa _build \
-D buildtype=release \
-D prefix=/usr \
-D sysconfdir=/etc \
-D platforms=x11,wayland,drm,surfaceless \
-D dri-drivers= \
-D gallium-drivers=lima,kmsro,swrast \
-D vulkan-drivers= \
-D dri3=true \
-D egl=true \
-D gles1=true \
-D gles2=true \
-D glx=dri \
-D libunwind=true \
-D lmsensors=true \
-D osmesa=gallium \
-D shared-glapi=true \
-D valgrind=false \
-D tools=meson configure _build
ninja $NINJAFLAGS -C _build
compiled package can be found here > http://gs.dread.fr/arch/armv7h/mesa-lima-20.0.0_devel.1.ce52b49-1-armv7h.pkg.tar.xz
i use xserver 1.20.6 on 5.4.1 kernel
just needed put the xorg mesa conf and rename the sun4i-drm_dri with an underscore
without the xorg conf it work too, with 100 fps less on glxgears
Did you use the 0.4 Image or the deot191111 image?
don’t miss your socks under the fireplace 
2 Likes
I haven’t thoroughly checked the change logs of vanilla 0.4 vs. DEOT 1.0 (which technically is 0.4), but in theory, they shouldn’t be too different, besides a different boot screen, theme, and additional “thematic” apps. (that for the most part are technically useless, but add “flavour”)
0.4 is technically slightly further ahead, from what I’ve gathered.
If it helps the original post of this thread documents every change I made, besides the most recent mesa/lima updates; since I couldn’t edit it after 1 month.
On a side note, are the mesa/lima libs stored in the user home directory now no longer needed, after having made a custom apt?
That’s another thing that the 191122 image has that the 191111 and stock 0.4 image doesn’t have.
If I have time, i’ll try and rebuild retroarch and mupen64+ to see if they work on either image. It’s strange that Retroarch only segfaults on the 191111 image, and not the 191122 one! Also, re: mupen64, you’re probably already aware of how hit and miss it is re: compatibility, but just for the record, which roms did you test? Just so i can test the same ones, to note any changes etc.
@guu (or anyone else involved in internal development) - Before we make too much headway into trying to put together an image using 0.4 as a base, do you have an info on whether or not there will be any drastic internal changes that will make this image obsolete? Should we wait for a fresh image with the newly discovered implementations/improvements? Or would the new image possibly even be loosely based upon what we have done here? No worries if you can’t say one way or another 
In kernel 5.4 I didn’t change the driver name from sun4i-drm to sun4i_drm,so if you are using a 5.4.x kernel,it not needed to run the command:
sudo mv /usr/lib/dri/sun4i-drm_dri.so /usr/lib/dri/sun4i_drm_dri.so
So it’s a good idea to make a link of sun4i-drm_dri.so for compatibility purpose.
PS:
I have seen a new repository been created on Github, and it seems like a software center.@guu do we have any news about new official version of OS?
1 Like
I was trying to avoid using mesa git and it did work on my 0.4 image without it. Also the deb packages inside of the mesa-repo are compiled from git so the files should be the same.
They shouldn’t be needed anymore as the repo will supply the same libs.
Retroarch does work but tries to use OpenGLES2 through X11 which lima (at least in this implementatiton) doesn’t seem to support. Many of the default settings that were used in the old implementations will not work or simply cause RetroArch to crash. (setting input driver to linuxraw used to work but will now crash as it tries to grab inputs from the video driver. Using sdl2 as video, audio and input driver will work perfectly though. I can upload my retroarch.cfg so you have a working setup to start configuring retroarch from. For mupen I just tried banjo kazooie but I also got errors when trying to do anything in mupen inside the terminal.
Compiling Retroarch did also fail on this image but that seems to be because the package libegl-mesa0 only installs “libEGL-mesa.so.0” and “libEGL-mesa.so.0.0.0” . If make fails with ld error missing -lEGL-mesa , moving into the directory of “libEGL-mesa.so.0.0.0” and doing “sudo ln -s libEGL-mesa.so.0.0.0 libEGL-mesa.so” should do the trick (I guess. I didn’t have any time to try it out yesterday)
PSA:
When using my image or any image that has been upgraded to buster, please look out for wifi issues. I’m having trouble connecting to certain wifi networks (or even finding them at all) that worked before and I don’t know if it’s related to buster or if it’s just my CPI being faulty.
1 Like