Env vars, placed into .bashrc, lxqt start, xbindkeysrc & LXSESSION script (@ my specifically KNOPPIX'ED Arch Linux)
(Sorry, I do not fully comprehend difference between env, export, printenv, set, „=” & declare...)
declare -x __GL_SYNC_TO_VBLANK="0" declare -x __GL_YIELD="USLEEP"
The first one „flattens” circumstances where glxgears test gives FPS rate result around 1.
•Monotonic uptime now: 23:13:45.417555.
•Compiz ALT+TAB static switcher (+wall/etc... that 're dependent to static switcher even actually turn on!) plugin have black background, often in this part of tests – visually sign that threading model of desktop environment and Open GL user applications changed. I see it several series this time so far.
Because it doesn't matter „effectability”, when more important is stability.
I remember that Linux „everywhere” has some threading problems, from an udev non completing in time at boot (worser thing is two GLX Xorg modules mixing!! And generally the Xorg conf.), through lower ext FS partition HDD efficiency with secure sync mounting, to problems with long lag new-tab console terminal opening.
But the last one is subjective... . Except the thing, that BFQ, RT kernels, etc. not helping ALSO in... ALSA sound system („rarely”) lagging [and still with 1 MB–1 CPU approach].
RT kernel?
Is is linked that someone's wrote Linux games (GODOT engine...) with CPU-demanding approach, something as it would be programmed in Java, the IT internal dysthopia of using C# and Java /remember blog users: Python is OK!!/ .RT kernels seem to be SCAM – it is better even to install Wayland INSTEAD of changing the Linux kernel style.
Even both Xterm and NVIDIA GT 610 work with Wayland (KWin_*Wayland* ver. works fine under RebbeccaBlack Live ISO OS, and NOT completes starting (bug?) under main Arch Linux OS).
Generally, you have
•GTK
•Qt
•and mere (U)Xterm, etc.
— working OK with Wayland.
But Wayfire WM is WORSER (under-worked!) than compiz.
Khronos page too difficult fore me. At least now. I not want mess with GL/X/ES internals so deep!!! Why the standarization when (to show the minimum of „ice block”) you NOT have Wayland on proprietary, and DO HAVE on nouveau, on the same system.
Switching NV and Nouveau modules no problem, but Wayland is a problem.
– HaShem ten ezrat... ba dvarim ken zeh...
We need strong Holy Spirit Ruach HaKodesh to have peace with IT systems at its current state.
The Linux stereotype of „Use Nouveau all times when encountered bug under proprietary driver” – pure nonsense.
If you users convince me to apply „new Khronos group tips”, after reneval of Khronos site – then, maybe, yes. But only with that state.
Generally, IT is much overmarketed. We need more printed stuff, NOT Apple/iOS/Google/Samsung smartphones/iPods/iPads/tablets.
