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
No comments:
Post a Comment