xcb fatal error[Bug]: #2798
Comments
|
It was working last night. I updated and it just broke |
|
How are you setting your wallpaper image? |
It's through xfconf query xfce4 xfdesktop |
|
Hmm, I'm guessing when disabling |
It did not solve the problem it still crashes with same problem. I use picom but even after killing picom and disabling it. It crashes nonetheless. I dont fully understand this line also |
|
Ok so a new discovery. Whenever I set my background through feh and then use polybar it works but will crash again if launched again. So everytime feh has to be used. |
Are you using the config you posted above? I don't see any way for this error to happen with this config. It theoretically can only happen with pseudo-transparency or with a tray.
That's just an internal error caused by the previous errors, it's not really relevant. Alright, if setting the background with feh doesn't crash polybar, it means that polybar makes some wrong assumptions about the way the wallpaper is set and xfce4 violates those assumptions. Can you run polybar with trace logging ( Could you also post the output of the following command? |
|
Actually I updated system and it started working. |
|
For more clarifications I still use xfdesktop to set wallpaper and now the system works flawlessly. Earlier I had to run |
|
So you never experiences this issue again? Do you know which packages you updated? Especially the xfce ones? |
|
Update broke again. My linux updated through a cron script and this time xfdesktop update broke polybar again |
|
In that case, can you post the output of polybar crashing with trace logging? Also, can you figure out which packages where upgraded (and between which versions)? |
|
It gives the same error my last upgraded packages found by |
|
I need the polybar output with trace logging, it contains some debug information that should be helpful here. You can get that by running the
This command generally gives you all packages you ever upgraded (or at least since you last deleted |
|
output of |
The background_manager used the root window depth for creating its pixmaps, but when the root pixmap has a different depth, this causes the copy_area_checked call to fail and crash the bar. We now load the root pixmap before finding the visual and creating the slice pixmaps. Fixes polybar#2798
The background_manager used the root window depth for creating its pixmaps, but when the root pixmap has a different depth, this causes the copy_area_checked call to fail and crash the bar. We now load the root pixmap before finding the visual and creating the slice pixmaps. Fixes polybar#2798
|
Thanks, my hunch was right. I think I was able to fix the issue in #2813. Do you mind trying out the fix and telling me if it worked? |
|
I am sorry if I sound rude but I cannot build it from source I will update you when it gets rolled on aur polybar-git |
|
No worries. I can provide you a I'd rather first check that the fix works before merging it. |
|
Alright, here is the # Maintainer: Patrick Ziegler <p.ziegler96@gmail.com>
_pkgname=polybar
pkgname="${_pkgname}-git"
pkgver=3.5.6
pkgrel=1
pkgdesc="A fast and easy-to-use status bar"
# aarch64 is not officially supported by polybar, it is only listed here for convenience
arch=("i686" "x86_64" "aarch64")
url="https://github.com/polybar/polybar"
license=("MIT")
depends=("libuv" "cairo" "xcb-util-image" "xcb-util-wm" "xcb-util-xrm"
"xcb-util-cursor" "alsa-lib" "libpulse" "libmpdclient" "libnl"
"jsoncpp" "curl")
optdepends=("i3-wm: i3 module support")
makedepends=("cmake" "git" "python" "pkg-config" "python-sphinx"
"python-packaging" "i3-wm")
backup=("etc/polybar/config.ini")
provides=("polybar")
conflicts=("polybar")
source=("${_pkgname}::git+https://github.com/patrick96/polybar.git#branch=fix/2798-root-pixmap-depth")
sha256sums=("SKIP")
pkgver() {
git -C "${_pkgname}" describe --long --tags | sed "s/-/.r/;s/-/./g"
}
prepare() {
git -C "${_pkgname}" submodule update --init --recursive
mkdir -p "${_pkgname}/build"
}
build() {
cd "${_pkgname}/build" || exit 1
# Force cmake to use system python (to detect xcbgen)
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 ..
cmake --build .
}
package() {
cmake --build "${_pkgname}/build" --target install -- DESTDIR="${pkgdir}"
install -Dm644 "${_pkgname}/LICENSE" "${pkgdir}/usr/share/licenses/${_pkgname}/LICENSE"
} |
|
Just tested it yes. It works flawlessly. no xcb error. Thank you very much. |
|
Thanks a lot for testing it out. I will merge the PR now. |
The background_manager used the root window depth for creating its pixmaps, but when the root pixmap has a different depth, this causes the copy_area_checked call to fail and crash the bar. We now load the root pixmap before finding the visual and creating the slice pixmaps. Fixes #2798
|
@patrick96, we're encountered the same issue in picom. if you're interested, it's because |
|
@absolutelynothelix Thanks for the insight. I never though about the root pixmap ( |
|
@patrick96, it turned out to be a little bit more complicated. xfdesktop creates it's desktop window, manages it and sets the |
Checklist
Steps to reproduce
polybar
Minimal config
Polybar log
Expected behavior
polybar should work with bars launched
Actual behavior
I don't fully know how but it gives error about xcb error
Window Manager and Version
xfwm4 4.16.1-3
Linux Distribution
Arch linux
Polybar version
Additional Context / Screenshots
The text was updated successfully, but these errors were encountered: