xlibre done right

A reply to my post on X about xlibre lead me to decide to test it once more.  Since I went through the process of starting from nothing to get xorg working, maybe this is what I needed to do to get xlibre working.  Could it possibly be that unknown remnants of xorg conflicted in unforseen ways with the xlibre parts I installed?  Might the mish mosh of software have caused my difficulties?

The only way I would find out is to go through a familiar process, but this time, instead of restoring xorg as my GUI, I would be installing xlibre.  The first step like previously, is to remove everything and I chose to remove pkg itself too.  After I did pkg delete -a -f I realized that I forgot to first update the xlibre repo if it was needed, but git was removed with everything else and shortly after firefox died as well.  I shifted out of the likely unstable potentially suddenly exiting fvwm3 instance to work on the commandline.

Luckily I still had access to the xlibre-ports git repo via my little sony music player android device.  I looked at the instructions and since I already had a possibly non-updated repo, I could still use it to prove if my suspicions or postulated theory were true.  I changed into the xlibre-ports directory and issued make clean, and then make install.  This time I just let everything install to see what it would actually do.

The long process of building from source was interrupted by a conflict between lang/py311-cython3-3.1.3 and an already installed older version of the same thing.  I cured this by simply doing pkg remove py311-cython and the older version was no longer a conflict.  I resumed the long build process until xlibre-xf86-video-qxl failed to build.  Since I have no idea what qxl is used for and I know I have never used it, I chose to try hiding the directory in xlibre-ports/x11-drivers in a new directory there named .hid and then resumed the building.  The script or process attempted to return to the qxl driver build but gave a message about it being "nonexistent" and then went to the next driver, and eventually finished.

I couldn't startx because x11/xinit was not installed, and I knew that of course that wouldn't help much if I didn't have a number of other things installed.  I added fvwm3 and xterm, and chose to try to startx.  As a precaution, before I even began the rebuild, I made sure to swap my scfb optimized .fvwm/local.config.scfb file in the last lines of the .fvwm/config by commenting out the .fvwm/local.config line and also editing the .Xresources file to modify for Xft.dpi: 64 just in case it helped a possibly bad (low) resolution desktop.  When I did start X, I was pleasantly surprised, aside from those adjustments for the possible vesa desktop making some things extra small.  I had an xlibre GUI with fvwm3 running and it was working.  My next steps were to pkg install the missing items: feh, dclock, umix, bluefish, firefox.

Starting firefox gave a weird error about not finding fonts, which was something I had never seen as a problem before.  Surely I normally had plenty of fonts installed.  Bluefish also started up in an odd fashion, but after I rebuilt my local repo of luanti, whatever bluefish needed was satisfied and maybe firefox would have been also were I not trying to build it from source to solve that font issue.  I doubt that a from source build of firefox would have cured it but it was the solution I immediately jumped toward.  It turned out that firefox could not finish building due to a strange error, so I reinstalled it via pkg and as I thought earlier, it now worked fine.

It seems that the moral to a story in three parts (the whole experience I wrote on this blog, prior posts and this one) is to start fresh when trying or switching to xlibre.  This could be done by removing everything using pkg the way I did, maybe best first to set a snapshot in zfs which I did not do, or to use a clean jail and figure out how to access or run xlibre from it.  Beware unknowingly mixing xorg and xlibre software because it seems that you may get rather unexpected unknowable results instead of what one may believe should be a smooth transition from one to the next.

Since everything seems to be working fine, I do not plan to go through the long process of switching back to using xorg.  I will remain a user of xlibre until I have a strong and compelling reason to clean the slate and start over again, whether that is xlibre refreshed or xorg with all of its unmaintained "glory" once more.  I think I like the idea of xlibre, just as I like the idea of neovim, both are substantial cleanups (or will be) and properly supported instead of languishing and buggy.

Broke GUI recovery

Recently I tested xlibre on my system without a safety net which tends to be my usual method.  As mentioned in the previous blog post, I was stuck again using scfb because of unknown reasons.  After many attempts to reinstall rebuilt ports or reinstall pkgs that I knew would be necessary to help me back to a usable GUI on a 4k screen, I gave up.  I wasn't making any progress, and even desktop-installer was no help this time, so I chose to start from nothing instead.  I issued pkg delete -a -f and then tried pkg info to prove that nothing lingered.  This was when pkg reminded me that it was removed also and needed to be bootstrapped back into the system.  This was easy, just had to answer 'y' to the prompt.

Many of my troubles are self-inflicted but some are due to various other things I may encounter though I do not know whether its unique to my situation.  I have in the past encountered issues with various things except that because of how I may be non-standard or do not always use the accepted official way to do things, I cannot report them.  All of this means that when I get myself into trouble, when I break my system softwarewise, I will need to find my own way out of the forest, rarely are any easy breadcrumbs scattered on the ground.

Since I have been through this a few times, although on my newer box which means many files I created with lists of things and other stuff are not present.  Those are possibly still on my former at present 'software + filesystem' broken system.  I know even from recent posts which things I need to reinstall.  What I didn't know about these things is all the stuff that each one installs as dependencies, so starting from nothing will look different than the reinstalls I did not long ago.

First was graphics/mesa-dri which gave me graphics/mesa-libs and graphics/libdrm which had been seperate steps in the past, now I know that was redundant.  Along with those I got graphics/libglvnd and graphics/glslang as well as a long list of things.

devel/autoconf
devel/autoconf-switch
devel/automake
devel/binutils
devel/bison
devel/bsddialog
security/ca_root_nss
devel/ccache
devel/cmake-core
sysutils/coreutils
textproc/expat2
devel/gettext-runtime
devel/gettext-tools
graphics/glslang
devel/gmake
math/gmp
misc/help2man
sysutils/htop
misc/hwdata
print/indexinfo
devel/jsoncpp
x11/libX11
x11/libXau
x11/libXdamage
x11/libXdmcp
x11/libXext
x11/libXfixes
x11/libXrandr
x11/libXrender
x11/libXv
x11/libXxf86vm
graphics/libdrm
devel/libedit
devel/libffi
graphics/libglvnd
converters/libiconv
dns/libidn2
archivers/liblz4
devel/libpciaccess
devel/libtextstyle
devel/libtool
devel/libunistring
devel/libuv
x11/libxcb
textproc/libxml2
x11/libxshmfence
textproc/libyaml
devel/llvm19
lang/lua53
lang/lua54
devel/m4
graphics/mesa-dri
graphics/mesa-libs
devel/meson
math/mpdecimal
math/mpfr
devel/ninja
security/openssl
devel/p5-Locale-gettext
devel/p5-Locale-libintl
converters/p5-Text-Unidecode
textproc/p5-Unicode-EastAsianWidth
devel/pcre2
lang/perl5.42
ports-mgmt/pkg
devel/pkgconf
ports-mgmt/portconfig
devel/py-babel
textproc/py-CommonMark
devel/py-Jinja2
textproc/py-alabaster
www/py-beaker
devel/py-build
devel/py-calver
security/py-certifi
textproc/py-charset-normalizer
lang/cython
textproc/py-docutils
devel/py-flit-core
devel/py-future
devel/py-hatchling
dns/py-idna
graphics/py-imagesize
devel/py-installer
textproc/py-mako
textproc/py-markdown
textproc/py-markdown-it-py
textproc/py-markupsafe
textproc/py-mdit-py-plugins
textproc/py-mdurl
textproc/py-myst-parser
devel/py-packaging
devel/py-pathspec
misc/py-pexpect
devel/py-pluggy
devel/py-ply
sysutils/py-ptyprocess
textproc/py-pygments
devel/py-pyproject-hooks
net/py-pysocks
textproc/py-pystemmer
devel/py-pyyaml
textproc/py-recommonmark
www/py-requests
devel/py-setuptools
devel/py-setuptools-scm
textproc/py-snowballstemmer
textproc/py-sphinx
textproc/py-sphinx-markdown-tables
textproc/py-sphinxcontrib-applehelp
textproc/py-sphinxcontrib-devhelp
textproc/py-sphinxcontrib-htmlhelp
textproc/py-sphinxcontrib-jsmath
textproc/py-sphinxcontrib-qthelp
textproc/py-sphinxcontrib-serializinghtml
devel/py-trove-classifiers
devel/py-typing-extensions
net/py-urllib3
devel/py-wheel
devel/py-wheel044
lang/python311
devel/readline
security/rhash
graphics/spirv-tools
devel/swig
print/texinfo
x11/xcb-proto
devel/xorg-macros
x11/xorgproto
x11/xtrans
archivers/zstd

After all of that was built and installed and cleaned, I went to the next essential item, graphics/drm-kmod which gave me all of the amd, intel, and radeon kmod files but pkg origin which was how I got these lists after the fact did not show the specifics of the numerous chipset names.  No sense listing those multiple duplicates here though they were actually different at install.

graphics/drm-66-kmod
graphics/drm-kmod
graphics/gpu-firmware-amd-kmod
graphics/gpu-firmware-intel-kmod
graphics/gpu-firmware-kmod
graphics/gpu-firmware-radeon-kmod

Next I should have been smarter about it but since graphics was my main issue previously, I was too focused on that aspect not to also focus solely on installing the amdgpu graphics driver.  Later I installed the x11-drivers/xorg-drivers after configuring it for what I specifically needed, a pkg install would include scfb and vesa and maybe intel drivers, all of which I do not want, do not use, and generally do not need.  So as I have mentioned before, I build xorg-drivers from source each time.  The one interesting thing about starting from very little already installed, is that xorg-drivers/xf86-video-amdgpu also installs xorg-server.  I hadn't noticed my error about not installing all the other drivers until after I got fvwm3 reinstalled, but the list from the xorg-drivers install is below, not quite in the pkg origin order it would have given.

archivers/brotli
devel/evdev-proto
print/freetype2
x11-fonts/libXfont2
x11/libXi
graphics/libepoxy
x11-fonts/libfontenc
security/libgcrypt
security/libgpg-error
devel/libudev-devd
devel/libunwind
x11/libxcvt
x11/libxkbfile
textproc/libxslt
x11/pixman
graphics/png
x11-drivers/xf86-video-amdgpu
x11/xkbcomp
x11/xkeyboard-config
x11-servers/xorg-server
x11/libXxf86vm
x11-drivers/xf86-input-keyboard
x11-drivers/xf86-input-libinput
x11-drivers/xf86-input-mouse

One note about the x11-drivers/xf86-input-libinput driver option, it leads to libinput whose config is to avoid the checked by default wacom option which also may lead to webcamd, I do not need either of those.  Except for that, I mostly chose to accept all defaults.  After I installed the amdgpu driver I chose to install x11/xinit which is where I get startx for later use.  The last thing I needed to get a usable desktop was x11-wm/fvwm3 and I generally use the much more recent fvwm3-dev which I keep updated on my own.  What I forgot again was that I did not have x11/xterm installed and this is not added by fvwm3, so at the time I had to reset my pc to exit the gui because I only had the graphics driver installed (though I present it not in this order above).  When I noticed xterm was needed after I added the input drivers, I still had to exit fvwm3 but could use the menu option.

Once I had xterm installed and was back in fvwm3, I could add the other missing items, feh, gkrellm2, umix, bluefish, and firefox.  A few things had an issue with cython installing as a dependency, so to save time, I installed them by pkg even though I keep my own feh-dev updated somewhat regularly.  Many things were still configured for the much smaller screen scfb would permit me to use, so I may want to adjust some of that, but aside from other things I may realize are not present I am done with recovery from my non-recommended xlibre test method.

Now a recap for the recovery from nothing, because these notes are more likely to remain than any hand-written paper.  Below includes a few configurations and a proper ordering of steps.  Note that any desktop environment such as KDE or similar is very extensive and may have a lot of the below as dependencies itself.

 1. pkg delete -a or pkg delete -a -f which will also remove pkg itself.
 2. make install clean for each of the following port origins, or pkg install if you like all defaults.
 3. graphics/mesa-dri provides mesa-libs, libdrm, libglvnd, glslang
 4. graphics/drm-kmod provides gpu-firmware-amd-kmod, gpu-firmware-kmod
 5. Configure x11-drivers/xorg-drivers for amdgpu (your preferred graphics driver), keyboard, libinput, mouse
 6. Configure x11/libinput to untick libwacom
 7. x11-drivers/xorg-drivers provides configured drivers and x11-servers/xorg-server
 8. x11/xinit provides startx
 9. x11/xterm
10. x11-wm/fvwm3 (your preferred mininmalist window manager)
11. startx

xlibre for a moment

It took some effort for me to get xlibre functional for myself, and with a few caveats.  My first attempt failed because I forgot to deinstall or pkg remove the former xorg-server and xf86-drivers.  Once I had all the old things removed, I was able to mostly install xlibre.  The trouble with how things in the github readme describe the process is that by following it, you will have everything installed.  There is also the small flaw with the git clone command provided, it should be "git clone https://github.com/b-aaz/xlibre-ports.git" instead.  I cloned the xlibre-ports repo and did a merge request to correct it.  As far as the remaining instructions, I mean that regardless of how you may choose to configure each sub-group for what it might install, the meta install will not honor it.  I could have suffered through this long process of installing everything, installing things I would never need, except that a dependency for one of the esoteric video drivers failed to install.

My solution was to ignore the meta installer, to go through those sub groups instead one by one, individual by individual as needed, in order for me to get the whole set of essential ports built and installed.  After I finally was sure that I had installed everything, I quit my session of FVWM3 and started it back up.  It seemed like everything was working but to be sure, I rebooted, got back to a shell prompt and tried to startx.  I shouldn't have been too surprised when it failed, but instead of the issues I had when I first switched to 15-stable, it turned out to be that the amdgpu driver was unable to load or with it X was unable to find a screen.

Back to the old standby I suffered recently, scfb? Actually no, because it has not been adjusted in whatever arcane ways to make it function with xlibre.  I am now, until I choose to revert to xorg-server and not use xlibre, stuck with the even worse vesa driver.  I am at present editing this post with bluefish after doing as much as I could to get many things adapted to the dpi vesa permits.  Even after that effort, bluefish seems to have a minimum window size or I didn't discover how to squeeze it into the screen I am allowed.

When I investigated the amdgpu driver situation, I found that when I was using xorg-server, the driver was 22.0.2 but the xlibre amdgpu driver is 22.0.1 and I expect that the slightly updated version would solve my issue.  Since it seems like the xlibre driver must be obtained from the xlibre-drivers repo, I cannot simply swap from one to the other with a small edit, as far as I know.  For now it looks like I will be revisiting xlibre at a later date when I might have noticed the amdgpu driver modified for it is updated.  The vesa driver is also much too slow to use for the one game I play most frequently, so that is another reason to go back to xorg-server for the time being.

Since that editing session, my blog post was saved in bluefish, I reverted to xorg-server, and tried many times to get the amdgpu driver to be used.  I am baffled at the moment about what is wrong but surely I will eventually solve the issue.  Regardless, I am now back to xorg and using the scfb driver.  My various adjustments to attempt to make the desktop fit everything while using the vesa driver now permit things to fit quite nicely with scfb.  I look forward to hearing more about xlibre and its future commits, future updates, and will be watching the xlibre-ports repo somewhat closely.

---

I've realized after publishing the above, that if this blog post were taken by itself, you may not know that I use the -stable branch shortly after it is cut from -current, and this means I am using 15-stable right now.  On my present box I have mostly tried to use just pkgs but when the one-size-fits-most defaults conflict with my desires, I build my own from ports, especially xorg-drivers.  My post about scfb shows that I generally avoid it, since oddly it will deny the amdgpu driver from being used.  I try to keep very current on a number of things in my github repos, particularly luanti and fvwm, but also feh and flameshot.  My system has an AMD Ryzen 3 3200G with Radeon Vega Graphics (3800.08-MHz K8-class CPU) and 128GiB RAM.

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.