So I looked at the xorg log file (which lives at /home/cpi/.local/share/xorg) and here’s what seems to be the relevant part:
[ 30.754] (II) Module modesetting: vendor="X.Org Foundation"
[ 30.754] compiled for 1.20.4, module version = 1.20.4
[ 30.754] Module class: X.Org Video Driver
[ 30.754] ABI class: X.Org Video Driver, version 24.0
[ 30.755] (II) LoadModule: "fbdev"
[ 30.755] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 30.774] (II) Module fbdev: vendor="X.Org Foundation"
[ 30.774] compiled for 1.20.0, module version = 0.5.0
[ 30.774] Module class: X.Org Video Driver
[ 30.774] ABI class: X.Org Video Driver, version 24.0
[ 30.774] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 30.774] (II) FBDEV: driver for framebuffer: fbdev
[ 30.775] (II) modeset(0): using drv /dev/dri/card1
[ 30.775] (WW) Falling back to old probe method for fbdev
[ 30.775] (II) Loading sub module "fbdevhw"
[ 30.775] (II) LoadModule: "fbdevhw"
[ 30.775] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 30.781] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 30.781] compiled for 1.20.4, module version = 0.0.2
[ 30.781] ABI class: X.Org Video Driver, version 24.0
[ 30.782] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 30.782] (II) modeset(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 30.783] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[ 30.783] (==) modeset(0): RGB weight 888
[ 30.783] (==) modeset(0): Default visual is TrueColor
[ 30.783] (II) Loading sub module "glamoregl"
[ 30.783] (II) LoadModule: "glamoregl"
[ 30.783] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
[ 30.947] (II) Module glamoregl: vendor="X.Org Foundation"
[ 30.948] compiled for 1.20.4, module version = 1.0.1
[ 30.948] ABI class: X.Org ANSI C Emulation, version 0.4
[ 34.562] (II) modeset(0): Refusing to try glamor on llvmpipe
[ 34.587] (EE) modeset(0): glamor initialization failed
[ 34.587] (II) modeset(0): ShadowFB: preferred NO, enabled NO
[ 34.594] (II) modeset(0): Output None-1 has no monitor section
[ 34.595] (II) modeset(0): EDID for output None-1
[ 34.595] (II) modeset(0): Printing probed modes for output None-1
[ 34.596] (II) modeset(0): Modeline "320x240"x59.8 5.80 320 326 328 388 240 242 244 250 +hsync +vsync (14.9 kHz eP)
[ 34.596] (II) modeset(0): Output None-1 connected
[ 34.596] (II) modeset(0): Using exact sizes for initial modes
[ 34.596] (II) modeset(0): Output None-1 using initial mode 320x240 +0+0
[ 34.596] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[ 34.596] (==) modeset(0): DPI set to (96, 96)
[ 34.596] (II) Loading sub module "fb"
[ 34.596] (II) LoadModule: "fb"
[ 34.605] (II) Loading /usr/lib/xorg/modules/libfb.so
[ 34.610] (II) Module fb: vendor="X.Org Foundation"
[ 34.610] compiled for 1.20.4, module version = 1.0.0
[ 34.610] ABI class: X.Org ANSI C Emulation, version 0.4
[ 34.611] (II) UnloadModule: "fbdev"
[ 34.611] (II) Unloading fbdev
[ 34.611] (II) UnloadSubModule: "fbdevhw"
So I’m guessing lima is not being used. (I have it chosen in the launcher gui.)
I guess I’ll try rebuilding mesa. (That seems cleaner than taking the arch version?) I’ve already grabbed a lot of libraries for box86 stuff, but that’s been isolated – I’m not sure how comfortable I feel grabbing libraries and replacing core system components with them. 
What packages should I remove from my system before installing mesa that I build? Is it the ones listed on the conflicts line in your script?
conflicts=('mesa' 'opencl-mesa' 'libva-mesa-driver' 'mesa-vdpau' 'libglvnd' )
Based on the xorg log, I think my version should be recent enough.
Is there anything else I’ll need to do or should the new mesa start picking up lima and supporting it when it’s installed? And while I honestly haven’t changed the setting from lima to fbturbo in 0.5 (except just in the past day to see if it could somehow turn lima back on), do you think whatever the launcher is doing will still allow me to switch if I update mesa? Or will I be on lima all the time? (Im not sure I care too much if I’m stuck in lima, but I figured it would be good to ask.)
Thanks!
EDIT:
I made progress on building mesa, but I hit a roadblock. There were quite a few dependencies I was missing, but I added them as meson stopped and threw errors. At least until it got here:
I’m not sure where I can get the “sensors” library. There are a number of packages listed when I do apt-cache search sensors |more and I don’t know which one I need, or if it even can be installed via package. So for now I’ve given up on rebuilding mesa.
However, the thread over here sent me down an interesting path:
I still have the lima drivers in place. And running dmesg|grep lima and cat /sys/class/drm/card0/device/uevent I get output that matches what was listed there, so lima is there are ready to go.
However, my ~/launcher/.xorg_lima.conf does NOT look like the one in that post – mine looks like this:
Section "Device"
Identifier "Allwinner A10/A13 FBDEV"
Driver "modesetting"
Option "fbdev" "/dev/fb0"
Option "SwapbuffersWait" "true"
EndSection
So instead of “lima” I have “modesetting”. So I just changed that to lima.
I also found this post:
And my /etc/ld.so.conf.d/00-arm-linux-gnueabihf.conf looked like this:
# Multiarch support
/lib/arm-linux-gnueabihf
/usr/lib/lima
/usr/lib/arm-linux-gnueabihf
I moved the lima line to the top since it sounds like that will cause it to get used before anything else.
I’ll reboot now and see what kind of mess I’ve made. 