Realitive @include path no long works in v10 when symlinks are used

[chrishoage]

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-5d150

Extensions:

• 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

1. In picom.conf use the @include directive with a relative path
2. start picom
3. change path to an absolute path
4. 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

[absolutelynothelix]

can't reproduce. can you reproduce it starting from commit 882025092f52585fa5c88fef297a12472ec73314? if no, then it seems to be fixed already.

[chrishoage]

Interesting! I was using the published version in the arch repos.

I will build and try to see if I can reproduce this weekend.

[chrishoage]

@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.

[absolutelynothelix]

@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.

[chrishoage]

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!

[absolutelynothelix]

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).

[chrishoage]

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.

[chrishoage]

@yshui Do you have any thoughts on the above investigation and possibly reverting https://github.com/yshui/picom/commit/a8b15f3a1b9111d0e0facd0ea413e8566a9d0a58?

[noctuid]

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.

[chrishoage]

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?

[yshui]

Would it be enough if picom also searches in a fixed directory? e.g. $XDG_CONFIG_HOME/picom/include.

[chrishoage]

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?

[yshui]

In this example would I just do @include common.conf in picom.conf and it would search $XDG_CONFIG_HOME/picom/include?

Yes, would that solve your problem?

[chrishoage]

Yes, it would. I could symlink common.conf to the include dir and preserve my system specific picom.conf files.