picom
picom copied to clipboard
Realitive @include path no long works in v10 when symlinks are used
Platform
Arch Linux
GPU, drivers, and screen setup
Nvidia 2070 Super, 1440p 144hz and 1650p 60hz
Environment
bpswm https://github.com/chrishoage/dotfiles
picom version
❯ picom --version
vgit-5d150
Diagnostics
**Version:** vgit-5d150Extensions:
- Shape: Yes
- XRandR: Yes
- Present: Present
Misc:
- Use Overlay: No (Another compositor is already running)
- Config file used: /home/chris/.config/picom/picom.conf
Drivers (inaccurate):
NVIDIA
Backend: glx
- Driver vendors:
- GLX: NVIDIA Corporation
- GL: NVIDIA Corporation
- GL renderer: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2
Backend: egl
- Driver vendors:
- EGL: NVIDIA
- GL: NVIDIA Corporation
- GL renderer: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2
Configuration:
Configuration file
❯ cat picom.conf
@include "common.conf"
vsync = false;
❯ cat common.conf
shadow = false;
inactive-opacity = 1.0;
active-opacity = 1.0;
frame-opacity = 1;
inactive-opacity-override = false;
blur-background-exclude = [
"window_type = 'desktop'",
"class_g = 'Bspwm' && class_i = 'presel_feedback'",
"class_g *?= 'firefox'",
"class_g *?= 'google-chrome'"
];
fading = false;
mark-wmwin-focused = true;
mark-ovredir-focused = true;
detect-rounded-corners = true;
detect-client-opacity = true;
detect-transient = true;
detect-client-leader = true;
backend = "glx";
glx-copy-from-front = false;
glx-no-stencil = true;
use-damage = true;
resize-damage = 5;
wintypes: {
tooltip: {
focus = true;
}
}
blur: {
method = "dual_kawase";
strength = 10;
background = true;
background-frame = false;
background-fixed = false;
}
opacity-rule = [
"0:_NET_WM_STATE@[0]:32a = '_NET_WM_STATE_HIDDEN'",
"0:_NET_WM_STATE@[1]:32a = '_NET_WM_STATE_HIDDEN'",
"0:_NET_WM_STATE@[2]:32a = '_NET_WM_STATE_HIDDEN'",
"0:_NET_WM_STATE@[3]:32a = '_NET_WM_STATE_HIDDEN'",
"0:_NET_WM_STATE@[4]:32a = '_NET_WM_STATE_HIDDEN'",
"40:class_g = 'Bspwm' && class_i = 'presel_feedback'",
"100:class_g = 'mpv'",
"100:class_g *?= 'firefox'",
"100:class_g *?= 'google-chrome'"
];
Steps of reproduction
- In picom.conf use the
@include
directive with a relative path - start picom
- change path to an absolute path
- start picom
Expected behavior
relative path functions
Current Behavior
relative path does not function. This did work in v9
❯ picom
[ 11/19/2022 10:09:49.600 parse_config_libconfig FATAL ERROR ] Error when reading configuration file "/home/chris/.config/picom/picom.conf", line 1: cannot open include file
[ 11/19/2022 10:09:49.600 main FATAL ERROR ] Failed to create new session.
Stack trace
OpenGL trace
Other details
This only happens when the configuration is symlinked in place
~/.config/picom
❯ l
lrwxrwxrwx 46 chris 8 Jan 2021 common.conf -> ../../dotfiles/bspwm/.config/picom/common.conf
lrwxrwxrwx 52 chris 8 Jan 2021 picom.conf -> ../../dotfiles/bspwm-laptop/.config/picom/picom.conf
can't reproduce. can you reproduce it starting from commit 882025092f52585fa5c88fef297a12472ec73314? if no, then it seems to be fixed already.
Interesting! I was using the published version in the arch repos.
I will build and try to see if I can reproduce this weekend.
@absolutelynothelix I built next
HEAD and I can still repo.
I dug a little deeper after your report of not being able to reproduce and the issue is when the config files are symlinked into place (i use stow to manage my dotfiles)
~/.config/picom
❯ l
lrwxrwxrwx 46 chris 8 Jan 2021 common.conf -> ../../dotfiles/bspwm/.config/picom/common.conf
lrwxrwxrwx 52 chris 8 Jan 2021 picom.conf -> ../../dotfiles/bspwm-laptop/.config/picom/picom.conf
I will update the title and body of the issue to reflect this.
@chrishoage, i’ll try to dig into this but i suspect it may be libconfig’s issue rather than picom’s. thank you for additional information.
i suspect it may be libconfig’s issue rather than picom’s. thank you for additional information.
That makes sense! If it turns out to be an issue with that library, I will happily go open a issue on that side with whatever information I need for them.
Thank you very much!
well, i've finally looked into this and... i can reproduce, @yshui broke it in a8b15f3a1b9111d0e0facd0ea413e8566a9d0a58 :D
i've read commit description and for me old behavior wasn't really confusing, so i'd personally revert that commit, but the final decision is on you two guys.
basically, when the config is a symlink and it contains relative include,
- old behavior was to resolve it relatively to the symlink itself
- new behavior is to resolve it relatively to the real file symlink points to
so now picom tries to find your common.conf
at .../dotfiles/bspwm-laptop/.config/picom/
. it could work, but it's located in another folder (just bspwm
instead of bspwm-laptop
).
Thank you for the investigation!
i've read commit description and for me old behavior wasn't really confusing
I happen to agree. When a file is symlinked and read from the symlinked location I would expect that any relative lookup would occur from where the symlink is not where the symlinked file actually is. My perception of symlink is to make a file behave as if it is not actually at the location it exists at. One could have a set of files colocated in one location and symlinked to the proper location and even the proper name,
i'd personally revert that commit, but the final decision is on you two guys.
If we're not comfortable with revering that commit, the only alternative I can think of is to expand environment variables so I could use @include "$HOME/.config/picom/common.conf"
, or have a built in expansion for ~
to getenv("HOME")
.
I feel that the new behavior is a bit unexpected, and may be simpler to just revert the new behavior. However maybe some sort of expansion is worth the effort.
@yshui Do you have any thoughts on the above investigation and possibly reverting https://github.com/yshui/picom/commit/a8b15f3a1b9111d0e0facd0ea413e8566a9d0a58?
However maybe some sort of expansion is worth the effort.
This would also be super useful for settings, e.g. I want to set corner-radius
to an environment variable I am using elsewhere (like in polybar) that is set based on my screen dimensions.
This is still problematic for me - wondering if there may be other solutions to be considered?
One idea I had was to allow picom --include-dir=$HOME/.config/picom
That should allow the existing default behavior where the real path of the config file is used to resolve the include dir, but allow users like myself where that behavior is undesirable to set the include dir.
Would something like this be better suited for consideration @yshui @absolutelynothelix?
Would it be enough if picom also searches in a fixed directory? e.g. $XDG_CONFIG_HOME/picom/include
.
Yes, that would work - the important thing to me is I can symlink files into a known location and read those symlinks with out a fully qualified path.
E.g. @include common.conf
which is symlinked relative to the main picom.conf.
In this example would I just do @include common.conf
in picom.conf
and it would search $XDG_CONFIG_HOME/picom/include
?
In this example would I just do
@include common.conf
inpicom.conf
and it would search$XDG_CONFIG_HOME/picom/include
?
Yes, would that solve your problem?
Yes, it would. I could symlink common.conf
to the include dir and preserve my system specific picom.conf
files.