Support for MX and antiX Linux distros
http://www.forum.mxlinux.org/
I'm currently using Picom as the go-to compositor in the custom MX system I'm running on several computers. Built it from the most recent sources available on github, and use it with Fluxbox. Thinking along the same lines, a while ago I was also going to suggest (or at least hint at) potentially making Picom the default compositor in the Fluxbx version of MX, but the current version needed some hackish solutions on my part to make it work seamlessly [edit: at least on the systems I have it running, all of those have integrated graphics], so I decided not to suggest it for now. Namely, it doesn't play nice with Virtualbox when running it in a guest, and I needed to write a script for launching it that checks the running system's virtualization status, and when running on actual metal it launches using the glx backend, when running on the oracle VM architecture it launches using the xrender backend. It also still left glitchy trails on screen in some situations in Fluxbox without turning off the damage monitoring ("damage" in this case meaning the parts of the screen that need to be redrawn, not any actual damage), stuff like that. Still, having now used it for a good while, keeping these tweaks/hacks in mind, it has been a very solid compositor and I quite like it - but at the moment it didn't seem like a problem-free general choice for a Fluxbox distro that should work out of the box in as many use cases as possible.siamhie wrote: Fri Feb 14, 2025 7:28 pm I was going to suggest fluxbox adopt picom over compton because compton hasn't been updated in 9 years.
Code: Select all
# Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`.
# `xrender` is the default one.
#
backend = "glx"
#backend = "xrender";
Yeah, glx most of the time for me as well.siamhie wrote: Sat Feb 15, 2025 12:46 am @Nokkaelaein Which backend is your config using? The default is xrender but I've switched to glx.
Code: Select all
picom -bcf --backend glx -D 20 -O 0.25 -I 0.25 -l -13 -t -13 -r 15 -o 0.8 --blur-method none --vsync --no-use-damage --no-fading-destroyed-argb --shadow-exclude 'class_g = "conky"'
Thanks for the detailed report.Nokkaelaein wrote: Fri Feb 14, 2025 9:38 pmI'm currently using Picom as the go-to compositor in the custom MX system I'm running on several computers. Built it from the most recent sources available on github, and use it with Fluxbox. Thinking along the same lines, a while ago I was also going to suggest (or at least hint at) potentially making Picom the default compositor in the Fluxbx version of MX, but the current version needed some hackish solutions on my part to make it work seamlessly [edit: at least on the systems I have it running, all of those have integrated graphics], so I decided not to suggest it for now. Namely, it doesn't play nice with Virtualbox when running it in a guest, and I needed to write a script for launching it that checks the running system's virtualization status, and when running on actual metal it launches using the glx backend, when running on the oracle VM architecture it launches using the xrender backend. It also still left glitchy trails on screen in some situations in Fluxbox without turning off the damage monitoring ("damage" in this case meaning the parts of the screen that need to be redrawn, not any actual damage), stuff like that. Still, having now used it for a good while, keeping these tweaks/hacks in mind, it has been a very solid compositor and I quite like it - but at the moment it didn't seem like a problem-free general choice for a Fluxbox distro that should work out of the box in as many use cases as possible.siamhie wrote: Fri Feb 14, 2025 7:28 pm I was going to suggest fluxbox adopt picom over compton because compton hasn't been updated in 9 years.
When speaking of glitches/hacks with picom's current version, are you referring to v/9.1 (bookworm) - or latest build v/12.5 ?Nokkaelaein wrote: Fri Feb 14, 2025 9:38 pm-- snip --
... but the current version needed some hackish solutions on my part to make it work seamlessly [edit: at least on the systems I have it running, all of those have integrated graphics] -- snip --
The latest one, i.e. built it from the available current version from github. Sorry about being ambiguous there; everything I thought out loud above is about my experiences with that github version, not the old one in the MX repo.ceeslans wrote: Sat Feb 15, 2025 6:34 am When speaking of glitches/hacks with picom's current version, are you referring to v/9.1 (bookworm) - or latest build v/12.5 ?
Nokkaelaein wrote: Sat Feb 15, 2025 4:23 amYeah, glx most of the time for me as well.siamhie wrote: Sat Feb 15, 2025 12:46 am @Nokkaelaein Which backend is your config using? The default is xrender but I've switched to glx.
Usually I'm passing it directly as a command line parameter, based on whether it's running inside a VM or not. So on this laptop I'm currently writing this with, picom has been launched with something like:
Code: Select all
picom -bcf --backend glx -D 20 -O 0.25 -I 0.25 -l -13 -t -13 -r 15 -o 0.8 --blur-method none --vsync --no-use-damage --no-fading-destroyed-argb --shadow-exclude 'class_g = "conky"'
Code: Select all
/usr/share/doc/picom/examples/picom.sample.conf
Yes.
Just to let you know, I was able to get it built.Stevo wrote: Sat Feb 15, 2025 5:51 pm OK, I'm giving it a try. It needs a backport of libconfig-dev first...maybe that's why the version directly from github is problematic?
I did download the source for picom 12.5 back in Nov and only had to install 3 dev libraries for it to build.
Yes, probably I had: libconfig Dependency libconfig found: NO found 1.5 but need: '>=1.7'Stevo wrote: Sat Feb 15, 2025 5:51 pm OK, I'm giving it a try. It needs a backport of libconfig-dev first...maybe that's why the version directly from github is problematic?
@Stevo I was only following what the readme said. All the dev libraries for Debian systems.Stevo wrote: Sun Feb 16, 2025 1:50 am Siamhie's success in building it is a bit odd in this light, to be honest.
Code: Select all
### Dependencies
Assuming you already have all the usual building tools installed (e.g. gcc, python, meson, ninja, etc.), you still need:
* libx11
* libx11-xcb
* xproto
* xcb
* xcb-util
* xcb-damage
* xcb-xfixes
* xcb-shape
* xcb-renderutil
* xcb-render
* xcb-randr
* xcb-composite
* xcb-image
* xcb-present
* xcb-glx
* pixman
* libconfig
* libdbus (optional, disable with the `-Ddbus=false` meson configure flag)
* libGL, libEGL, libepoxy (optional, disable with the `-Dopengl=false` meson configure flag)
* libpcre2 (optional, disable with the `-Dregex=false` meson configure flag)
* libev
* uthash
On Debian based distributions (e.g. Ubuntu), the needed packages are
```
libconfig-dev libdbus-1-dev libegl-dev libev-dev libgl-dev libepoxy-dev libpcre2-dev libpixman-1-dev libx11-xcb-dev
libxcb1-dev libxcb-composite0-dev libxcb-damage0-dev libxcb-glx0-dev libxcb-image0-dev libxcb-present-dev
libxcb-randr0-dev libxcb-render0-dev libxcb-render-util0-dev libxcb-shape0-dev libxcb-util-dev libxcb-xfixes0-dev
meson ninja-build uthash-dev
```