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 the 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 onthe commandline.
Luckily I still have 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 a 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 py311-cython3-3.1.3 and an already installed older version of the same thing. I cured this by simply doing a 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 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 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.
No comments:
Post a Comment