Jump to content

KDE + KWin compositor performance on NVIDIA GPU


UCyborg

Recommended Posts

I've setup a Manjaro Linux with KDE desktop environment back in July on my desktop PC and out-of-the box, the desktop is quite laggy (mouse response, window animations fluidity). I've skimmed through this topic, changed KWin rendering backend from OpenGL 2.0 to OpenGL 3.1 and created the executable script that sets certain environment variables at ~/.config/plasma-workspace/env/kwin.sh:

#!/bin/sh

export KWIN_TRIPLE_BUFFER=0
export __GL_YIELD=USLEEP
export __GL_MaxFramesAllowed=1

Seems better, though there are still moments when window animations are choppy. None of the options above are what I'd consider radical. Reading about triple buffering it doesn't sound like something I'd want considering the input lag and the fact that it's system-wide settings. ForceFullCompositionPipeline seems ever more of a mystery in this context...I have 2 screens simply running at their native resolution and 59,93 Hz and 60 Hz refresh rates, so nothing special here.

The GPU is NVIDIA GTX 750 Ti, using proprietary NVIDIA driver version 465.31 that came with Manjaro.

Just curious about others' experiences and thoughts in the similar situation (KDE with enabled compositor + proprietary NVIDIA driver).

Edited by UCyborg
Link to comment
Share on other sites


I had similar issue on my test system with debian 11 and KDE, but also had mouse glitching out on compositor enabled (black box where mouse was sometimes). On me problem ended after switching off from proprietary NVIDIA driver to free one, but then lost most of 3d features and had lower performance on anything using hardware accerlation. Gpu I used was 1050 2gb. It is not distro specific issue rather driver. Does free driver make different? Manjaro has device manager that allows toggle between free and non free driver, so reverting is easy

Edited by Mr.Scienceman2000
Link to comment
Share on other sites

From my personal view, KDE always makes the impression of being inefficent and ressource-heavy. I couldn't run that on the computers that are older than yours. Maybe try a different window manager to see if the performance is better? Is it worth KDE?

Link to comment
Share on other sites

After some more testing performing repetitive actions, opening program windows and minimizing/restoring them, it doesn't appear those environment variables are actually making any difference. One user reported he just set KWIN_TRIPLE_BUFFER to 1 and it made things better without enabling it at driver level. Tried that too and it's not any better and likewise doesn't seem worse neither.

Maybe power management makes things seem inconsistent along with whatever you're doing at any one moment. The old Ubuntu MATE 15.10 install definitely did not scale performance up well automatically (ondemand power governor), at least it was noticeable with games. It tried to keep lower frequencies too much, resulting in stutter.

I used Compiz on the old Ubuntu install. It wasn't exactly on the level of Windows 10's DWM performance, but was a bit smoother than KWin on this system. Could also set rendering rate, I put it 1 frame below screen refresh rate to improve mouse responsiveness. I tried installing it while running live image of Manjaro (for testing) from USB but AUR server blocked me midway with HTTP error 429 while downloading/checking dependencies with (I ran pamac build compiz-easy-patch in the terminal).

The laptop with AMD Radeon R2 definitely fares better with KWin. It's got 1366x768 screen, though it probably shouldn't make too much difference, considering such GPUs these days don't have much of a problem driving even multiple (cca. 2-3 screens). At least not those that don't do fancy resolutions like 4K.

The compositor is even more easily bogged with nouveau driver. As for KDE, well, it's got most of bells and whistles I could ever ask for. :thumbup The only unrelated characteristic that I don't even know how to word the search term to find out on the internet how to change, some programs' certain GUI elements are really big, things like text fields, menu strips, buttons. I'd like to make them smaller.

Link to comment
Share on other sites

No wonder those variables don't make much difference as effect of the one was already applied and the other one was just a workaround according to this. I set VSync option to "Only when cheap" (at least I think it's called this in English) and it's better, at least it does't bring back tearing when scrolling web pages. But simple things still slow it down tremendeously, like having a notification on screen, even when running both CPU and GPU at max clocks.

Link to comment
Share on other sites

On 9/3/2021 at 4:50 AM, UCyborg said:

The laptop with AMD Radeon R2 definitely fares better with KWin. It's got 1366x768 screen, though it probably shouldn't make too much difference, considering such GPUs these days don't have much of a problem driving even multiple (cca. 2-3 screens). At least not those that don't do fancy resolutions like 4K.

Amd drivers are better on linux than Nvidia. Even though they are not perfect. I was never able to make AMD hd cards work proper under Linux. I had laptop with AMD R8 and AMD driver caused any desktop to hang since power management error that spammed console. Interesting enough same error did not appear on legacy mode only uefi. Only error free is Intel igpu but those cannot run games or other 3d intensive things properly

Link to comment
Share on other sites

3 hours ago, Mr.Scienceman2000 said:

Amd drivers are better on linux than Nvidia.

That's not what they were saying years ago. Want good 3D on Linux? NVIDIA is your only option. That was the word. And they did prove themselves, I still remember the blog post of Dolphin Emulator developers about their experience with different drivers. Though people said 2D was worse, I assumed this applied to window managers that don't do compositing.

The main reason to get NVIDIA then was to get decent OpenGL support, which was historically bad with ATI/AMD, even on Windows, let alone Linux.

Either way, it's what I got ATM and I don't buy new graphics card every 2 years, obviously. Even this one doesn't get much exercise anymore and the spare cards I got (ATI Radeon HD 4890 and onboard NVIDIA GeForce 8200) are only worse as far as Linux compatibility is concerned.

Link to comment
Share on other sites

1 hour ago, UCyborg said:

That's not what they were saying years ago. Want good 3D on Linux? NVIDIA is your only option. That was the word. And they did prove themselves, I still remember the blog post of Dolphin Emulator developers about their experience with different drivers. Though people said 2D was worse, I assumed this applied to window managers that don't do compositing.

i mostly meant if can use AMDGPU driver it works great for most part, but AMDGPU only works with new ones for most parts. I was diagnosing one pc with ATI Radeon HD 6800 I think and my way test any system I got is fire up linux on it since got full desktop from pendrive. I had black screen on after grub and loading text and though gpu was broken until did swap to console mode and had warnings. So AMD only partially fixed it recently, but unless got RX series GPU you are SOL.

1 hour ago, UCyborg said:

The main reason to get NVIDIA then was to get decent OpenGL support, which was historically bad with ATI/AMD, even on Windows, let alone Linux.

ATI Windows drivers were trash. Omega drivers were half decent to them since they fixed most ATI shortcomings.

1 hour ago, UCyborg said:

Either way, it's what I got ATM and I don't buy new graphics card every 2 years, obviously. Even this one doesn't get much exercise anymore and the spare cards I got (ATI Radeon HD 4890 and onboard NVIDIA GeForce 8200) are only worse as far as Linux compatibility is concerned.

that compatibility with graphics card and other hw is why I cannot go linux full time. Many claims linux will magically work on older hw which is in reality is not true. I have had issues with older Broadcam wifi cards, intel wifi card flashed led like crazy by default, many times gpu lacks hw accerlation that works on Windows no issues. Maybe if all did is using office programs and browsing web can replace, but I still cannot get my hardware or software run under linux properly.

Link to comment
Share on other sites

Aye, the development is focused on what's current. Just the nature of the whole thing. It's kinda impossible to support everything, even if there wasn't an incentive to sell current stuff. Linux only got more steam over later periods of time and the things of past are frozen in their current state.

Link to comment
Share on other sites

1 hour ago, UCyborg said:

Aye, the development is focused on what's current. Just the nature of the whole thing. It's kinda impossible to support everything, even if there wasn't an incentive to sell current stuff. Linux only got more steam over later periods of time and the things of past are frozen in their current state.

Best soluction for me seems to be using older less updated versions like debian 9 or other works well. Maybe you could try oldstable builds instead of rolling releases like manjaro unless your mainboard or some of your utilities or other need newer linux kernel.

Link to comment
Share on other sites

I doubt current versions of stuff is much of a problem in this case. I'm mostly concerned with common Linux problems. Needed a bit of refresh after having the old rotting Ubuntu install without ability to pull anything from repos (which I haven't updated since it was installed or at least only updated shortly after installation, can't remember exactly). Can always nuke it and start over, possibly with another distro if something goes south. Not a lot of extra stuff to install and setup for my use.

My remark was concerning hardware that never had good support to begin with.

I imagine in the future it won't be possible to use last NVIDIA's drivers for my card with then bleeding edge and eventually LTS distros as well after NVIDIA drops driver support. Kepler cards were dropped this summer, I guess 1st gen Maxwell is next in 2 years. Unless has something has changed (or will change) and Linux folks have added backward compatibility for these types of drivers?

Edited by UCyborg
Link to comment
Share on other sites

  • 2 months later...

I turned off KWin's compositing in system settings and got picom to do the compositing instead, I have much smoother desktop now.

Installed it:

# Arch Linux based distros
# May need to update system first if last command doesn't work
sudo pacman -Syu
sudo pacman -S picom

# Debian / Ubuntu based ditros
sudo apt install picom

Copied its default config file to my home .config folder:

# Arch Linux based distros
cp /etc/xdg/picom.conf ~/.config/picom.conf

# Debian / Ubuntu based distros
cp /usr/share/doc/picom/examples/picom.sample.conf ~/.config/picom.conf

Adjusted it to my liking:

#################################
#             Shadows           #
#################################


# Enabled client-side shadows on windows. Note desktop windows
# (windows with '_NET_WM_WINDOW_TYPE_DESKTOP') never get shadow,
# unless explicitly requested using the wintypes option.
#
# shadow = false;
shadow = true;

# The blur radius for shadows, in pixels. (defaults to 12)
# shadow-radius = 12;
shadow-radius = 7;

# The opacity of shadows. (0.0 - 1.0, defaults to 0.75)
# shadow-opacity = .75;

# The left offset for shadows, in pixels. (defaults to -15)
# shadow-offset-x = -15;
shadow-offset-x = -7;

# The top offset for shadows, in pixels. (defaults to -15)
# shadow-offset-y = -15;
shadow-offset-y = -7;

# Avoid drawing shadows on dock/panel windows. This option is deprecated,
# you should use the *wintypes* option in your config file instead.
#
# no-dock-shadow = false;

# Don't draw shadows on drag-and-drop windows. This option is deprecated,
# you should use the *wintypes* option in your config file instead.
#
# no-dnd-shadow = false;

# Red color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-red = 0;

# Green color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-green = 0;

# Blue color value of shadow (0.0 - 1.0, defaults to 0).
# shadow-blue = 0;

# Do not paint shadows on shaped windows. Note shaped windows
# here means windows setting its shape through X Shape extension.
# Those using ARGB background is beyond our control.
# Deprecated, use
#   shadow-exclude = 'bounding_shaped';
# or
#   shadow-exclude = 'bounding_shaped && !rounded_corners';
# instead.
#
# shadow-ignore-shaped = '';

# Specify a list of conditions of windows that should have no shadow.
#
# examples:
#   shadow-exclude = "n:e:Notification";
#
# shadow-exclude = []
shadow-exclude = [
  "name = 'Notification'",
  "class_g = 'Conky'",
  "class_g ?= 'Notify-osd'",
  "class_g = 'Cairo-clock'",
  "_GTK_FRAME_EXTENTS@:c"
];

# Specify a X geometry that describes the region in which shadow should not
# be painted in, such as a dock window region. Use
#    shadow-exclude-reg = "x10+0+0"
# for example, if the 10 pixels on the bottom of the screen should not have shadows painted on.
#
# shadow-exclude-reg = "";

# Crop shadow of a window fully on a particular Xinerama screen to the screen.
# xinerama-shadow-crop = false;


#################################
#           Fading              #
#################################


# Fade windows in/out when opening/closing and when opacity changes,
#  unless no-fading-openclose is used.
#
# fading = false;
fading = true;

# Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028)
# fade-in-step = 0.028;
fade-in-step = 0.03;

# Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03)
fade-out-step = 0.03;

# The time between steps in fade step, in milliseconds. (> 0, defaults to 10)
# fade-delta = 10;

# Specify a list of conditions of windows that should not be faded.
# fade-exclude = [];

# Do not fade on window open/close.
# no-fading-openclose = false;

# Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc.
# no-fading-destroyed-argb = false;


#################################
#   Transparency / Opacity      #
#################################


# Opacity of inactive windows. (0.1 - 1.0, defaults to 1.0)
# inactive-opacity = 1.0;
# inactive-opacity = 0.8;

# Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default)
# frame-opacity = 1.0;
# frame-opacity = 0.7;

# Default opacity for dropdown menus and popup menus. (0.0 - 1.0, defaults to 1.0)
# menu-opacity = 1.0;

# Let inactive opacity set by -i override the '_NET_WM_OPACITY' values of windows.
# inactive-opacity-override = true;
inactive-opacity-override = false;

# Default opacity for active windows. (0.0 - 1.0, defaults to 1.0)
# active-opacity = 1.0;

# Dim inactive windows. (0.0 - 1.0, defaults to 0.0)
# inactive-dim = 0.0;

# Specify a list of conditions of windows that should always be considered focused.
# focus-exclude = [];
focus-exclude = [ "class_g = 'Cairo-clock'" ];

# Use fixed inactive dim value, instead of adjusting according to window opacity.
# inactive-dim-fixed = 1.0;

# Specify a list of opacity rules, in the format `PERCENT:PATTERN`,
# like `50:name *= "Firefox"`. picom-trans is recommended over this.
# Note we don't make any guarantee about possible conflicts with other
# programs that set '_NET_WM_WINDOW_OPACITY' on frame or client windows.
# example:
#    opacity-rule = [ "80:class_g = 'URxvt'" ];
#
# opacity-rule = [];


#################################
#     Background-Blurring       #
#################################


# Parameters for background blurring, see the *BLUR* section for more information.
# blur-method =
# blur-size = 12;
#
# blur-deviation = false;

# Blur background of semi-transparent / ARGB windows.
# Bad in performance, with driver-dependent behavior.
# The name of the switch may change without prior notifications.
#
# blur-background = false;

# Blur background of windows when the window frame is not opaque.
# Implies:
#    blur-background
# Bad in performance, with driver-dependent behavior. The name may change.
#
# blur-background-frame = false;


# Use fixed blur strength rather than adjusting according to window opacity.
# blur-background-fixed = false;


# Specify the blur convolution kernel, with the following format:
# example:
#   blur-kern = "5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1";
#
# blur-kern = '';
blur-kern = "3x3box";


# Exclude conditions for background blur.
# blur-background-exclude = [];
blur-background-exclude = [
  "window_type = 'dock'",
  "window_type = 'desktop'",
  "_GTK_FRAME_EXTENTS@:c"
];

#################################
#       General Settings        #
#################################

# Daemonize process. Fork to background after initialization. Causes issues with certain (badly-written) drivers.
# daemon = false;

# Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`.
# `xrender` is the default one.
#
# backend = "xrender";
backend = "glx";

# Enable/disable VSync.
# vsync = false
vsync = true;

# Enable remote control via D-Bus. See the *D-BUS API* section below for more details.
# dbus = false;

# Try to detect WM windows (a non-override-redirect window with no
# child that has 'WM_STATE') and mark them as active.
#
# mark-wmwin-focused = false;
mark-wmwin-focused = true;

# Mark override-redirect windows that doesn't have a child window with 'WM_STATE' focused.
# mark-ovredir-focused = false;
mark-ovredir-focused = true;

# Try to detect windows with rounded corners and don't consider them
# shaped windows. The accuracy is not very high, unfortunately.
#
# detect-rounded-corners = false;
detect-rounded-corners = true;

# Detect '_NET_WM_OPACITY' on client windows, useful for window managers
# not passing '_NET_WM_OPACITY' of client windows to frame windows.
#
# detect-client-opacity = false;
detect-client-opacity = true;

# Specify refresh rate of the screen. If not specified or 0, picom will
# try detecting this with X RandR extension.
#
# refresh-rate = 60;

# Limit picom to repaint at most once every 1 / 'refresh_rate' second to
# boost performance. This should not be used with
#   vsync drm/opengl/opengl-oml
# as they essentially does sw-opti's job already,
# unless you wish to specify a lower refresh rate than the actual value.
#
# sw-opti =

# Use EWMH '_NET_ACTIVE_WINDOW' to determine currently focused window,
# rather than listening to 'FocusIn'/'FocusOut' event. Might have more accuracy,
# provided that the WM supports it.
#
# use-ewmh-active-win = false;
use-ewmh-active-win = true;

# Unredirect all windows if a full-screen opaque window is detected,
# to maximize performance for full-screen windows. Known to cause flickering
# when redirecting/unredirecting windows.
#
# unredir-if-possible = false;
unredir-if-possible = true;

# Delay before unredirecting the window, in milliseconds. Defaults to 0.
# unredir-if-possible-delay = 0;

# Conditions of windows that shouldn't be considered full-screen for unredirecting screen.
unredir-if-possible-exclude = [
  "class_g %= 'Microsoft-edge-*'",
  "class_g = 'Pale moon'",
  "class_g %= 'Vivaldi-*'",
  "class_g = 'vlc'"
];

# Use 'WM_TRANSIENT_FOR' to group windows, and consider windows
# in the same group focused at the same time.
#
# detect-transient = false;
detect-transient = true;

# Use 'WM_CLIENT_LEADER' to group windows, and consider windows in the same
# group focused at the same time. 'WM_TRANSIENT_FOR' has higher priority if
# detect-transient is enabled, too.
#
# detect-client-leader = false;
detect-client-leader = true;

# Resize damaged region by a specific number of pixels.
# A positive value enlarges it while a negative one shrinks it.
# If the value is positive, those additional pixels will not be actually painted
# to screen, only used in blur calculation, and such. (Due to technical limitations,
# with use-damage, those pixels will still be incorrectly painted to screen.)
# Primarily used to fix the line corruption issues of blur,
# in which case you should use the blur radius value here
# (e.g. with a 3x3 kernel, you should use `--resize-damage 1`,
# with a 5x5 one you use `--resize-damage 2`, and so on).
# May or may not work with *--glx-no-stencil*. Shrinking doesn't function correctly.
#
# resize-damage = 1;

# Specify a list of conditions of windows that should be painted with inverted color.
# Resource-hogging, and is not well tested.
#
# invert-color-include = [];

# GLX backend: Avoid using stencil buffer, useful if you don't have a stencil buffer.
# Might cause incorrect opacity when rendering transparent content (but never
# practically happened) and may not work with blur-background.
# My tests show a 15% performance boost. Recommended.
#
# glx-no-stencil = false;

# GLX backend: Avoid rebinding pixmap on window damage.
# Probably could improve performance on rapid window content changes,
# but is known to break things on some drivers (LLVMpipe, xf86-video-intel, etc.).
# Recommended if it works.
#
# glx-no-rebind-pixmap = false;
glx-no-rebind-pixmap = true;

# Disable the use of damage information.
# This cause the whole screen to be redrawn everytime, instead of the part of the screen
# has actually changed. Potentially degrades the performance, but might fix some artifacts.
# The opposing option is use-damage
#
# no-use-damage = false;
use-damage = true;

# Use X Sync fence to sync clients' draw calls, to make sure all draw
# calls are finished before picom starts drawing. Needed on nvidia-drivers
# with GLX backend for some users.
#
# xrender-sync-fence = false;

# GLX backend: Use specified GLSL fragment shader for rendering window contents.
# See `compton-default-fshader-win.glsl` and `compton-fake-transparency-fshader-win.glsl`
# in the source tree for examples.
#
# glx-fshader-win = '';

# Force all windows to be painted with blending. Useful if you
# have a glx-fshader-win that could turn opaque pixels transparent.
#
# force-win-blend = false;

# Do not use EWMH to detect fullscreen windows.
# Reverts to checking if a window is fullscreen based only on its size and coordinates.
#
# no-ewmh-fullscreen = false;

# Dimming bright windows so their brightness doesn't exceed this set value.
# Brightness of a window is estimated by averaging all pixels in the window,
# so this could comes with a performance hit.
# Setting this to 1.0 disables this behaviour. Requires --use-damage to be disabled. (default: 1.0)
#
# max-brightness = 1.0;

# Make transparent windows clip other windows like non-transparent windows do,
# instead of blending on top of them.
#
# transparent-clipping = false;

# Set the log level. Possible values are:
#  "trace", "debug", "info", "warn", "error"
# in increasing level of importance. Case doesn't matter.
# If using the "TRACE" log level, it's better to log into a file
# using *--log-file*, since it can generate a huge stream of logs.
#
# log-level = "debug";
log-level = "warn";

# Set the log file.
# If *--log-file* is never specified, logs will be written to stderr.
# Otherwise, logs will to written to the given file, though some of the early
# logs might still be written to the stderr.
# When setting this option from the config file, it is recommended to use an absolute path.
#
# log-file = "/path/to/your/log/file";

# Show all X errors (for debugging)
# show-all-xerrors = false;

# Write process ID to a file.
# write-pid-path = "/path/to/your/log/file";

# Window type settings
#
# 'WINDOW_TYPE' is one of the 15 window types defined in EWMH standard:
#     "unknown", "desktop", "dock", "toolbar", "menu", "utility",
#     "splash", "dialog", "normal", "dropdown_menu", "popup_menu",
#     "tooltip", "notification", "combo", and "dnd".
#
# Following per window-type options are available: ::
#
#   fade, shadow:::
#     Controls window-type-specific shadow and fade settings.
#
#   opacity:::
#     Controls default opacity of the window type.
#
#   focus:::
#     Controls whether the window of this type is to be always considered focused.
#     (By default, all window types except "normal" and "dialog" has this on.)
#
#   full-shadow:::
#     Controls whether shadow is drawn under the parts of the window that you
#     normally won't be able to see. Useful when the window has parts of it
#     transparent, and you want shadows in those areas.
#
#   redir-ignore:::
#     Controls whether this type of windows should cause screen to become
#     redirected again after been unredirected. If you have unredir-if-possible
#     set, and doesn't want certain window to cause unnecessary screen redirection,
#     you can set this to `true`.
#
wintypes:
{
# tooltip = { fade = true; shadow = true; opacity = 0.75; focus = true; full-shadow = false; }
  dock = { shadow = false; }
  dnd = { shadow = false; }
# popup_menu = { opacity = 0.8; }
# dropdown_menu = { opacity = 0.8; }
};

I actually use refresh-rate = 59 on my system because primary screen uses 59.93 Hz refresh rate and explicitly setting it like that improves mouse responsiveness. Not anymore due choppy rendering. The config is simple, subtle shadows around window borders, fading effect when activating/deactivating windows, VSync, unredirection enabled for fullscreen windows - useful for games so only their own VSync applies if enabled, compositor gets out of the way either way to not have extra input lag, exceptions may be added as desired since some web browsers and video players may be unredirected when in fullscreen mode, therefore the result is screen tearing. xprop WM_CLASS -> click on the application to get its window class name, second string is needed. It's possible to use pattern matching to catch multiple windows with similar class name with one rule, used above to catch windows of different branches of certain Chromium based web browsers that I happen to know about. Vanilla Chromium and Firefox don't seem to need it. Some settings may need adjusting depending on the environment. Config changes apply as soon as the file is saved while picom is running.

For having picom auto-start, I researched how to get systemd to launch it, so I basically turned it into systemd managed service. Running:

systemctl --user --full --force edit picom.service

Will result in ~/.config/systemd/user folder being created if it doesn't exist yet where a text file picom.service will appear with the following content you paste in the editor that opens:

[Unit]
Description=Picom X compositor
Documentation=man:picom(1)
PartOf=graphical-session.target
StartLimitBurst=3
StartLimitIntervalSec=60

[Service]
ExecCondition=sh -c "~/check_x11.sh"
ExecStart=/usr/bin/picom
Restart=on-failure
RestartSec=10

[Install]
WantedBy=graphical-session.target

The above references script check_x11.sh, placed directly in user's home folder, it ensures Picom isn't started when logging into Wayland session since it only supports Xorg / X11:

#!/bin/bash

if [ "$XDG_SESSION_TYPE" == "x11" ]
then
    exit 0
else
    exit 1
fi

Then finally:

# Enable service auto-start and start it now
systemctl --user --now enable picom.service

You may be reading this in the future where the above may already be sufficient and results in picom starting after other services when it's supposed to at login, but otherwise, in case of using KDE desktop environment, it will only work if you have systemd version >= 246 and Plasma >= 5.21 and explicitly enable desktop environment setting to have Plasma services started up by systemd:

kwriteconfig5 --file startkderc --group General --key systemdBoot true

OTHER DESKTOP ENVIRONMENTS MAY NEED DIFFERENT STEPS TO GET IT WORKING PROPERLY WITH SYSTEMD! IT SHOULD ALSO BE ENSURED THAT THE DESKTOP ENVIRONMENT DOESN'T HAVE THEIR OWN COMPOSITOR OR HAVE IT DISABLED. EASIEST METHOD TO AUTO-START IS PROBABLY THROUGH DESKTOP ENVIRONMENT'S GUI FOR ADDING STARTUP ENTRIES, THOUGH THAT DOESN'T PROVIDE FACILITY TO RESTART IT IN ODD CASE OF FAILURE / CRASH.

The file mentioned in the above command is located in ~/.config folder. This desktop's services being managed by systemd is relatively recent development, there's still some room for improvement (Plasma and the systemd boot).

With the above disabled, picom may still be started by systemd by replacing using WantedBy=default.target in service config file under [Install] section. Reload this specific service's config by running:

systemctl --user reenable picom.service

default.target may cause it to start when it's not supposed to (console login?) so it won't be able to do anything and exit (and repeat that 2 more times). Following described procedures alone skips digging deeper into systemd specifics.

Edited by UCyborg
Link to comment
Share on other sites

  • 5 weeks later...

I messed up my Manjaro install. You really can't do partial upgrades without corrupting everything. :D

Went KUbuntu 21.10 since I'm a bit more at home with apt package manager and the ecosystem, ran sudo apt dist-upgrade to update everything, installed NVIDIA 495 series drivers.

Seems the current version of KWIN performs better than the one I had, or might have to do with other pre-release component and picked the bad moment to have the then current versions of everything.

What seems to help further here in desktop smoothness is switching over to Wayland instead of using the rusty old X11 (wrote too fast, actually slower overall, might test again in the future with newer driver, only version 495.44 in the repo ATM, but not 495.46), though it seems rough around the edges. Changing desktop background is really laggy at times (back on X11, using picom improved that), VLC crashes after finishing playback with presumably default OpenGL->GLX backend. Picking EGL instead of GLX fixes stability, but it results in bad performance for some reason, though EGL works fine under X11. The compromise would be X11 XCB backend (I'd have to check the exact English name), but I can't help but notice some frame drops with it. Seems VLC doesn't support Wayland yet, so has to run through XWayland. No luck with 4.x experimental version installed using Snap, doesn't launch, complains about being unable to lock media library.

Seems with Wayland there is no concept of primary screen anymore, judging by settings. KDE's night color doesn't work neither, can't find solution on the internet, probably the driver issue...

Firefox still doesn't seem to run WebGL as well as it should, a bit disappointing after seeing them close long opened ticket regarding the problem since it's supposedly fixed. Chromium's WebGL seems to be as fast as on Windows when running through OpenGL, though it appears translating to D3D11 is more helpful than it used to be (can speed up rendering). The text in chrome://flags still suggests native OpenGL should be more performant on NVIDIA, though that was written years ago.

Edited by UCyborg
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...