Trinity/TDE 14.1.2

[Grogan]

I finally got around to upgrading that, when I realized that what I had (whatever it was in their git repo at the time, probably 14.0.somethingish) was compiled on April 29 2020. Now that's robust.

It has gotten to be a much more persnickety, broken pain in the ass to compile since then, it seems. I do make it harder by insisting on doing things my way and putting them where I say they go, rather than just running some package building scripts that will turn on all the knobs and link everything with everything etc. and dump it all in /usr, though. First of all I grabbed their git repo like usual and found I was missing CMake macros to configure it. I couldn't find them anywhere I had permissions to clone from. So I found it in the release source tarballs, it's called tde-cmake-trinity they have to be installed system wide for cmake (/usr/share/cmake/Templates etc.). That probably would have worked, but due to other problems I was having I decided to just use the release tarballs for everything, it's fairly recent and after all, it's what has the changes they are crowing about in release notes anyway.

Next, I found that my usual way of building tqt3 (their maintained fork of QT3) isn't good enough anymore, I think I needed something from the database shit. I installed mariadb (mysql drop-in), postgresql, unixodbc and turned them on and that seemed to do it. It caused it to be missing something that arts CMake tests were looking for. *shrug* I still don't know for sure (a failed test will tell you that you don't have something but it just means the compile test failed), but building a more complete tqt3 worked.

Then I ran into a gcc 14.1.x issue with implicit declarations in one spot in the window manager, tdm's display manager back end. This has not changed in their current git repo either. Something was overriding my CFLAGS and just not taking them any way. It wasn't even making it into the generated Makefile for that directory. (I used the GNU make back end for CMake instead of Ninja, but neither worked in this case). The rest of the build was taking them. I couldn't figure it out after hours of screwing around, so I just declared the fucking thing myself. Even though this declaration is in <pthread.h> that the file includes, even though it really CAN be implicitly assumed, it's just frowny and gcc doesn't allow it for C anymore. However, it would allow it with -Wno-error=implicit-function-declaration if the naughty build would take them from -DCMAKE_C_FLAGS:STRING= in the CMake command as intended, for that directory. It's only C, that's already allowed in C++, it will take an implicit declaration with no "arguments" (heheh pun intended, but I mean function arguments () )

Code: Select all

--- a/tdm/backend/dm.c	2024-04-18 16:32:18.000000000 -0400
+++ b/tdm/backend/dm.c	2024-07-12 20:23:03.458496726 -0400
@@ -1716,6 +1716,10 @@
 #ifdef HAVE_SETPROCTITLE
 	setproctitle( "%s", name );
 #elif defined(HAVE_PTHREAD_SETNAME_NP)
+
+extern int pthread_setname_np (pthread_t __target_thread, const char *__name)
+     __THROW __nonnull ((2));
+
 	pthread_setname_np(pthread_self(), name);
 #elif !defined(NOXDMTITLE)
 	p = Title;

I just added that from /usr/include/pthread.h with empty lines so it would stand out from the rest of the function. The + lines were added to the file. People and their silly shit...

It was fairly smooth sailing after that. Set up taking far longer than the actual builds which take literally seconds (probably a minute for the big ones like libs and base). There was a time when it used to take me like 8 hours to build KDE 3 lol. It was better to just do single threaded builds, with no -j because it was too fast to see what was going on anyway, and when it stops on a failure it's easier to follow. Anyway, I built all the parts, and only the parts I use. All for alderlake instead of nehalem now as that old one that was built on the old computer on what was my manjaroo at the time.

It didn't lose any configuration, not a thing was out of place after it migrated the configs. It looks... pretty much the same as my TDE always looks. I love my blackened Keramik style. Except now I have that picom compositor, it's wonderful. That's real transparency there. Also, I'm getting a kick out of having animations in old X11 programs that have never had anything like that. That's because this sits above the client. I think it's affecting the card animations in my solitaire game too.

Here it is, my masterpiece that's been pissing me off since late last night, TDE 14.1.2

Right click and view image in new tab as this will be somewhat down scaled.

tde-14.1.2-desktop.jpg (378.14 KiB) Viewed 17105 times

[Grogan]

Oh yeah... I only build a few of the games (kshisen, kpat) but I added this one (ktuberling) this time so I could tease my nephew sometime while he's here. When he was little, back when I had KDE 3.x, I used to let him sit and play with that and he'd make a potato head guy and then, proud of himself, he'd get my attention and say "That's YOU!". I'm going to do that and see if he remembers

mrpotatohead.jpg (104.42 KiB) Viewed 17091 times

[Zema Bus]

Looks good! Wish modern Plasma would bring back that window theme.

Seems like I remember you posting the potato guy way back then

[Grogan]

I'm not sure, but I think TDE's display power management might be poisonous this time. A couple times I've come back to my computer unresponsive, display won't wake, no input devices work (no ctrl-alt-backspace or ctrl-alt-del or anything) but ACPI power button (tower) worked, so the kernel wasn't dead. I probably could have SSH'd in if I'd have had another box running.

The monitor seemed unhappy after that though. When I powered up again, it took a long time to display anything on screen, probably 10 seconds. It didn't show the boot loader and was into systemd init before the display mode switched to the amdgpu framebuffer console. I was also screwing around back and forth between two kernels too at the time because something changed my audio volume. (It wasn't Linux 6.10, it was something Arch updated and I wasn't paying attention, and routinely nuked my package cache... I was busy so I just said "Y" to all the packages and cleaned up). I have more knob on the speakers, but it pisses me off that volume levels got crippled. To be fair I'm not using pipewire though, and they do nuke the pulseaudio configuration files because we're not expected to mess with those. Maybe I'll find my answer in there.

I cleaned my system out today (I was compiling a kernel at -j24 but that would have been done in 1m30s, long before screen power interval). It was not very dirty at all. The case has very good screens and I've been cleaning the front one regularly since it's so easy... as soon as I see opacity. At that point (e.g. a few weeks) there's usually a thin, silky white covering on the front screen (probably fine dust from drywall ceiling tiles in this basement room etc.). The top screen never gets dirty, as the top fan blows up. Surprisingly (and this was the one I was most concerned about) the little screen underneath the PSU intake wasn't dirty. That one is a huge pain in the ass, I'll never get it back in with the tower upright because it just sits on these little mounts where it slides in and it's not guided. There was a little fine dust in the CPU cooler/fan but nothing that would have affected it significantly. That will be the first BJ for the CPU cooler since the rig was assembled.

Anyway, the display power management sliders correspond to what xset does but it may be doing something else. If a desktop environment has display power settings, disabling it IS something that turns it off completely (It has to work that way otherwise people would be all WTF lol) and it's not something that can be removed (I might be able to at compile time) because it's part of tdebase. So I disabled it and just put a .desktop file in .trinity/Autostart that runs a command in script. I already have two commands in "xseton" and "xsetoff" scripts that I use for pre and post game launch.

So my xseton.desktop file in .trinity/Autostart is just this:

Code: Select all

[Desktop Entry]
Type=Application
Name=xseton
Exec=/home/grogan/.config/xseton

and my xseton script is just this (X11 defaults, those values... this is what I'm used to and what I like. I'll handle it when I don't like it)

Code: Select all

#! /bin/sh
xset dpms 600 600 600

I think only the first value matters for LCD's, I have yet to see one that behaves any differently than shutting down to standby. EXCEPT, my current MSI monitor has a 60 second period where it goes into a less deep standby mode until it shuts off. It will wake more quickly. This is not affected by display power management preference though, it's just what it does before it shuts down. If I were to shutdown -h now it would do that after the computer shuts off. If I were to reboot it wouldn't shut all the way off and I'd see an image on my screen sooner etc.

We'll see what happens. It's been fine for several smoke breaks/trip to the store etc. There was also a lot of xorg packages (that I haven't compiled) that came from Arch recently. It is also possible that it's the picom compositor getting in the way. I'll know it's "something" if those xset settings have the same problem, because I have been using that forever.