Sorry to reawaken an old thread, but after doing some testing with ptitSeb on the latest box86 fixes, he pointed out that my Gameshell seems to be running software OpenGL instead of using Lima, based on what it was producing in the logs. But I have it set to Lima, so I’m not sure what’s going on.
I was trying to find the old thread I remember where someone mentioned (perhaps you?) how to check in the system for whether Lima is active (not just in the launcher). Anyhow, I went ahead and ran glxgears and came up with this:
The llvmpipe thing is what ptitSeb saw in the logs and why he suggested it was not using Lima after all. This is all on 0.5 official.
I’m wondering if I somehow accidentally clobbered my GL drivers in some of my testing and experimental builds? I think it’s unlikely but I’m wondering what others might get if they run glxgears -info @javelinface, care to give that a try and share your results? Maybe it is using Lima and just reports it weird. But I’d like to be more certain. Thanks!
I haven’t tried anything, but before I forget, I remember where there was some discussion re: Lima, and if it’s being used etc. it’s around the posts and below. It’s essentially where proper Lima drivers on the gameshell were born. Haha.
Also there seemed to be some talk of apps erroneously using OpenGL over Lima here:
A question. Did you apt upgrade to Buster? I seem to always have problems with Lima and other things breaking, up to the point that Retroarch doesn’t work at times. Ironically this is a major upgrade step when using the 0.4-0.5 upgrade script.
I’ve wrecked my sleep pattern trying to get other stuff to work on the gameshell, so prrrobably should get some sleep for once! I’ll have a look tomorrow at what glxgears outputs. (I’ll be up for another 4 hours if I start tinkering now haha; you know how it be ;))
I did upgrade to buster. With all the stuff I’ve been installing, it seemed necessary, and I thought I remembered reading that with 0.5, upgrading worked and no longer broke Lima. I guess I was wrong.
I haven’t had a chance yet to work through that first thread, but the link you provided seems to have plenty of answers. Digging through and figuring out what works and what doesn’t will be a bit of a chore though. And I’m pretty aure my Gameshell is not using Lima properly anymore, no matter what I pick in the launcher. Sounds like I’ll need to rebuild Mesa, though I saw mention in that thread of a prebuilt one that might work. I’m just hoping I won’t have to reflash my sd card and start over, because I’ve got a working build environment and other things I don’t want to lose, and starting over from scratch each time means I’m less likely to keep tinkering.
If I get It working and have a clear understanding of what I did to get there, I’ll try to write a new post with the information and steps I used. It’s unfortunate (and frustrating) that the Gameshell OS is so fragile and that the only documentation is scattered across buried posts in the forum. I appreciate the help from you and @r043v though!
@r043v can actually help you with knowledge! I’m but a retriever dog who has read all the posts in the forum, and can pull up information, and a willing and able guinea pig to test things on ;).
Also I know that feel re: losing the passion due to starting over. For that same reason, I’m constantly backing up images, and flashing spare SD cards to test things, before applying them to my main one.
Did you have spare SD cards to work with? I’m happy to throw a few bucks to a fellow game sheller, if money is tight. Your contributions are totally worth it!
I’ve got a spare card to test on, but I’m really hoping I can get things related to lima repaired on the current card. I’ve been using this one (256GB) to try lots of things, and build lots of things, and I’d probably want to archive as much as I could so I could move it to another card. All that is doable, but would just take a lot of time copying things back and forth (not to mention space to store it in the mean time).
I’m hoping I can figure it out, fix it, and continue to use this card as-is. But if not, I might take a break and try to archive and document as much stuff as I can. For instance, I could put some of the stuff I got working in the warehouse, and make notes of various things I tried to build that sort of worked or that didn’t work at all. (Related to that other thread, I actually did try to build Moonshell, but it seemed to require specific Raspberry Pi feature s we don’t have. It was also relatively easy to trick the script that runs Steamlink to try to run it on the Gameshell, but it also failed due to missing libraries. It might be possible to get running with the libbcm-host hacks mentioned elsewhere but I didn’t get that far, and I kind of doubt it would work anyway.)
Anyhow, it’s my own fault for using so much space for unfinished projects, but if I need to reinstall, I’ll want to take time and make sure I don’t lose anything I might regret. I’m not at that point yet though. I still need to see if I can figure out how to fix the Lima issue on this card.
I suppose on a positive note, it means that the box86 stuff that’s been running on my device will run even faster with Lima, once I get that working again.
If I do need to reflash, I’m also tempted to use the Arch variant @r043v put together. In some ways it sounds more stable, though I remember a post a while back listing some things it’s missing. I’ve more familiar with the Debian tools, but I wouldn’t be sad to see the launcher go, and it sounds like the fantasi launcher is more actively developed anyway. I’d just like to be able to do an update/upgrade (or whatever the Arch equivalent is) without having to worry I’ve destabilized the OS and broken the video drivers.
I still love the Gameshell though, as it’s already met and exceeded the hopes I had for it. And it still offers a lot of potential, as I’ve already seen remarkable things running on it. I just wish it was a bit more reliable/stable in terms of software.
Speaking of software there’s another thread on here somewhere about someone launching only retroarch and using it as the only main software on the device. I think an emulator focused build like that would probably be a great benefit to folks who only got the Gameshell to play ROMs. It’s capable of so much more, but a Retroarch focused OS with few other bells and whistles might be more bulletproof and would probably generate fewer problems and questions from the folks who chose to use it. Just a thought. (It wouldn’t be for the tinkerers though.)
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.)
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:
the mainline mesa debian just must not ship lima,
i don’t know if apt will let you uninstall mesa as it must be deps of some others packages
i think you may just recompile & install it, overwriting any other files
(for compile if it miss deps you may have to do sudo apt-get build-dep mesa
i used mainline arch linux arm mesa pkgbuild as base for gs one, the conflict list may contain gpu related (nvidia & co) who provide also mesa
I stupidly forgot to turn on my swap file, so I had to kill the build. I’ve rebooted, turned on swap, and have it going again (ninja $NINJAFLAGS -C _build). Looks like it’s going to take a while so I may just come back to it later when it’s done.
Hmm, this is all I have:
So I’m not sure where that lima configuration file is.
Maybe it doesn’t exist anywhere, but I’m not sure how it would have gotten deleted? I might try grepping around for “Lima” in *.conf files across the entire system and see what I find.
I already seem to have sun4i_drm_dri.so in place (as a copy):
Maybe all I need to do to get lima working again is create that config file? Is that something an apt-get upgrade might have deleted?
Oops, I just realized those files I posted above are in a different directory. I don’t even have a /etc/X11/xorg.conf.d/ at all!
if mesa-lima was manually installed into the system image upgrading mainline mesa will just let files without delete them
make a symbolic link is preferable as the link will everytime point on latest, a copy can be forgiven ^^
for speedup a bit the compilation process if you need to recompile it again you can remove wayland support from mesa configuration, it was enabled for me as i initially tried to have wayland instead of x11 in arch port
in clockworkos the conf may have been directly into /etc/xorg.conf ?
I checked the sun4i* files and one is now new, so that’s a good sign!
I just backed up the other one just in case, and then created the link.
And yes, it looks like you were right about the xorg.conf:
Although it kinda looks like the one in the launcher directory?
I’m not sure which one is being used. Should I change this one in /etc to match your config? Mine is missing both the ServerFlags section, and the “OutputClass” section and only has the “Device” section like the one in launcher.
Cool, I think I’ve got everything done except for the config. See my edited post above.
Switching between fbturbo and lima in the launcher yields the exact same result for glxgears:
GL_RENDERER = llvmpipe (LLVM 7.0.1, 128 bits)
GL_VERSION = 3.1 Mesa 20.0.0-devel (git-8405e1bef0)
GL_VENDOR = VMware, Inc.
So it’s not switching anything.
I also tried updating the /etc/xorg.conf to use this: