scfb our last resort

It seems that I am cursed to revisit the use of scfb as my graphics driver once more.  I ran into problems with my graphics again and I cannot say exactly why everything remained broken.  I looked over the Broke GUI recovery blog post I made to be sure I hadn't missed anything.  I did very similarly to how I described the steps at the end, but the amdgpu driver would not tell xlibre-server that there were screens for it.

pkg install 11vm
graphics/mesa-dri
graphics/drm-kmod
x11-drivers/xlibre-drivers
x11/xinit
x11/xauth
x11/xterm
pkg install rust
pkg install cargo-c
x11/libxkbcommon
x11/xrdb
x11/xset
x11/xrandr
fvwm

And later I added a few more things, three of them fill gaps in my fvwm environment.

graphics/feh
audio/umix
x11-clocks/dclock
www/librewolf

It used to be that our last resort graphics driver was vesa, but on a 4k monitor, this is truly a waste and as in the past, makes a GUI almost unusable.  Now our unwanted but functional option is scfb which has considerably better resolution but with some quirks.  If you switch to another tty for any reason, when you return your desktop may have a layer of black covering it, concealing any desktop graphic you may have.  This seems to be the only oddity and it may not even be due to scfb, I cannot be sure.

When I ran into by broken graphics issue, I assumed it was purely due to a large update of pkgs and perhaps something got uninstalled, or there may have been a conflict of versions in some way.  What confused me much longer than it ought to have, since I had been down this road before, was that I could get back to a simple text-only interface if I disabled the automatic load of the amdgpu kernel object.  Every time it tried to load it during boot, I would have a panic and reboot.  This made me believe there were other problems.  When I finally came to my senses and disabled the amdgpu from loading, I would no longer need to use single user for any changes.

The good and bad news became that even after the complete removal via pkg delete -af as I have done a few times now, and the reinstall of that list of things above, allowing amdgpu to load didn't cause a panic and reboot.  Now, if I try to startx all I get is the famously frustrating "no screens found" error.  I tried reinstalling different things, different versions of a few things, but no change in my situation.  So once again I wait for whatever it is that was broken outside of my control to be fixed again, but until then I use scfb our last resort.

Update:

This is what doesn't make sense to me.  I had reinstalled all those things, I also removed drm-kmod in favor of drm-515-kmod, but this did not cure the difficulty with the amdgpu driver being used, I was relegated to scfb.  I even saw in messages from xorg or dmesg, that there was an incompatibility with the kernel and the drm-kmod file.  Maybe that was when I installed via pkg, I am not completely sure, but even if so, I rebuilt it from source and that didn't solve anything.  And then I rebuilt and reinstalled kernel and world, and now graphics is functioning properly?  I noticed the extra small text in console that I have become accustomed to seeing as an indicator of things being loaded correctly.  After I booted the new kernel and world, I logged in to my user and started X and clearly I was back to using the amdgpu.

I thought I had a handle on all of this, but if graphics can be broken when it doesn't seem like it ought to be, and then mysteriously get fixed without touching any of the things I had installed for graphics, then I definitely am missing something.  For now I will treat this as a hiccup and continue with the assumption that everything I had done before I reinstalled kernel and world was precisely correct.  However, this blog post will remain so I can look back and as another last resort, maybe while I use scfb for a short time, try rebuilding and reinstalling kernel and world to see if that is an unusual cure again.

Stuck with scfb

What an unusual change, that once I did my best to keep the scfb driver uninstalled and now I have to use it.  I recently upgraded my system from 14-stable to the newly available 15-stable.  The usual process of updating src via git had a small hiccup due to a missing update to the blog post I perused.  The minor detail I missed was that git switched to using https and that was what stopped the /usr/src update.  All my blog posts now mention that git change where I had described the old method.  The update was quick and building kernel and world went smoothly as expected.

When I was booted into the 15-stable kernel with world, I knew I had a lot of adjusting to do with regard to installed software or any other changes.  I had saw an easy way to handle the task somewhere online.  What I did was pkg upgrade -f right after I used gitup ports to update the ports tree.  What I didn't know was that pkg was missing or not in a working state, so I had to do pkg bootstrap -f and after I did the pkg upgrade -f, I expected most things to just work.

You can make an educated guess that of course things did not work as expected or hoped.  When I tried to start the X server so I could get back to using my pc as normal, it failed, some errors that seemed to be related to a mismatch with the kernel.  I figured I could get past this issue by being certain to build locally with my updated ports tree.  I rebuilt graphics/mesa-dri which pulled in graphics/libdrm (and I believe graphics/mesa-libs which makes sense), next I rebuilt graphics/drm-kmod which also provided gpu-firmware-kmod, after that was x11-drivers/xf86-video-amdgpu, next was x11-servers/xorg-server, and finally x11/xinit.  I believed I had everything remade compatible with 15-stable and so I tried to start X again.

I must have assumed that I needed to reboot to have everything load properly, but this simply made me reboot a second time into single user so I could remove all the graphics stuff.  Only after the graphics drivers were not trying to load could I boot into text only.

With all that I rebuilt, it gave an error that seemed to be a conflict between drivers?  In the /var/log/Xorg.0.log file it seemed to load a raven driver and then picasso, but it couldn't find the amdgpu_picasso_gpu_info_bin file.  No matter how many times I repeated the rebuild process to be sure I hadn't made any mistakes, I got the same result.  The only way I could succeed to boot was to make sure the graphics was uninstalled, and usually I had to do that via single user.

With too many attempts already made, I remembered that there was the vesa driver which could work, and also the scfb driver I could try.  I installed vesa first and tested it to see an unusable former 4k desktop squeezed into 640 x 480, everything huge on my 4k monitor.  I didn't have mouse, so I couldn't exit fvwm or use an xterm to do anything, but I believe an alternate virtual tty was accessible, and I killed it from there.  Next was the scfb driver which had always wanted to get in the way of the amdgpu driver in the past.  When I got into X again, it was still quite large but much more usable.  I also cured the mouse issue by building the mouse driver which was mysteriously missing.

I have during and since been searching for any recent reports or information about this issue.  Most of the results are rather old, like 2019, or (of course) very Linux specific which does me no good, since their solutions are purely for that distro and its install methods.  I did see mention somewhere about a change to driver naming or something, I am very unclear on that.  That was in Linuxland, so if there was a change in that realm, we need to wait for it to be propagated into FreeBSD before maybe I will see a fix and get back to my amdgpu driver with 4k.  I don't believe there is anything more I can do besides wait, but I will likely keep trying to get away from scfb.

UPDATE:
That was pleasantly fast.  I suffered with graphics being broken and forced into second class scfb for my driver for only two or three days.  Moments after posting the above, I went to /usr/local/etc/pkg/repos to edit the FreeBSD.conf file to disable FreeBSD-ports-kmods, and then upgraded pkg and updated, and after all the drivers were reinstalled, I have my 4k back.  While I watched the update listing, it showed those graphics drivers did indeed all get updated to a more recent version.  I cannot say whether there was a problem in the drivers or if any file was missing, or if strangely those kmod files were not pulled from FreeBSD-ports-kmods repo if that happened before.  All that I can say right now is that my experience with the situation and my suffering scfb for a short time was documented above.  How ever things got corrected, I am grateful for the work by those involved.