Thanks for troubleshooting. It’s difficult for me to test issues when I don’t have bspwm edition regularly installed. Your input was very helpful.
1 Like
I’m glad I could be of help.
To add to @Chrysostomus thank you for not only reporting but following through with the results. As I have extra family business right now, my time is limited, so this is a helpful look into these issues.
@anon69008348
I’m aware of the picom issue however, as I am also testing the newest verstion of bspwm (0.9.10), I haven’t had a chance to hunt down which was causing the issue (picom update or bspwm update). I will start testing with removal of the Intel graphics line, thanks for checking this out.
The micro-manjaro issue I’ve looked at recently ( https://archived.forum.manjaro.org/t/micro-manjaro-micro-st-session-errors/156227 ). However, @Yochanan’s update seems to work excellently and solves the issues on my machine and I see OP posting similar results.
2 Likes
@airclay Thank you for the reply.
I did a little bit more troubleshooting. I can say it’s not related to Intel lines, it still happens randomly time to time. I tried different launch options according to man page but no luck. I also changed the default backend xrender to glx. And I’m 100% sure it’s not related to feh.
I also run it with log to see what happens and found this. I don’t know about details since I’m kinda new to this thing but hope it helps:
[ 09-09-2020 15:48:47.542 x_fence_sync ERROR ] Failed to trigger the fence (X error 136 XSyncBadFence request 134 minor 15 serial 1704)
[ 09-09-2020 15:48:47.542 paint_all ERROR ] x_fence_sync failed, xrender-sync-fence will be disabled from now on.
When it happens on a boot, only changes on the log file is serial 1704 to serial 1705.
[ 09-09-2020 15:59:18.815 x_fence_sync ERROR ] Failed to trigger the fence (X error 136 XSyncBadFence request 134 minor 15 serial 1705)
[ 09-09-2020 15:59:18.816 paint_all ERROR ] x_fence_sync failed, xrender-sync-fence will be disabled from now on.
1 Like
Check this thread and let me know if any of the info is of use?
[SOLVED] Failed to start picom with vsync_opengl_swc_init error / Applications & Desktop Environments / Arch Linux Forums](url)
I cannot reproduce the log error as you have although I am having the same high transparency issue on some launches. I actually am getting no errors or noticeable difference in “trace” level log whether I encounter the error or not.
This work for me. Although I didn’t understand what you refer to “restart it”. If it was related with picom, I tried picom, and the terminal gave me some error saying that the profile was in use.
Just for the record, in my case is a fresh install of BSPWM using Manjaro-Architect.
Did you run any commands or maybe restart bspwm between running the command pkill picom and trying to run picom? Reason I ask is the error is likely due to picom already running.
@anon69008348 @OvelixMax
I finally had the time to do more than some quick pokes.
The issue should be able to work around by commenting out the below opacity rule from ~/.config/picom like so:
opacity-rule = [
# "10:class_g = 'Bspwm' && class_i = 'presel_feedback'",
It seems there was an issue with a recently updated dependency. [picom] All windows get transparent / Applications & Desktop Environments / Arch Linux Forums
Reported fixed on the ‘next’ branch which should be install-able via picom-git. Picom incorrectly parses exclude rules with && symbol · Issue #470 · yshui/picom · GitHub
Note: I have had success with either solution, commenting the line vs installing picom-git
1 Like
@OvelixMax I probably meant for picom though restarting picom doesn’t always fixed the issue.
@airclay Not sure I follow this topic, will check again with clear mind.
This actually fixed the issue, so it was an opacity problem. It will be gone with the new picom version it seems.
Thank you.
By the way, not directly related to this topic but I want to ask before open a new topic. My current picom config (most likely the default one) causes tearing while watching videos or playing games. Disabling picom seems to fix tearing issue (it probably turned into stuttering but not so noticeable by me), shouldn’t it be other way around that picom fixes tearing?
Is it happening only with fullscreen video/games?
You can edit line in ~/.config/picom.conf like so:
unredir-if-possible = false;
https://wiki.archlinux.org/index.php/Picom#Flicker
Better explained here: "Flickering" when opening a new window or tooltip on a maximized window. · Issue #402 · chjj/compton · GitHub
1 Like
Thank you very much.
Yes it was only on fullscreen and unredir-if-possible = false; option fixed the issue.
I also saw a vsync option there and tried to turn it on with vsync = true; but it only caused picom to crash so had to disable it again.
Generally speaking, as an out of the box experience I still feel like Manjaro i3 edition was more ready to use comparing to Bspwm edition, though this was probably because I ran into some issues after the fresh installation. However I found Bspwm more snappy and easier to use. Since the issues are fixed now I think I can slowly start ricing. 
Thanks again and hope you have a nice day.
1 Like
Yes, there’s been some recent updates and we could use a fresh iso. Thanks though, these threads are helpful.
Here’s some more info about Nvidia/vsync, NVIDIA/Troubleshooting - ArchWiki
Here’s a cool script I’m using to dynamically rename the desktops, it’s not perfect when renaming desktops with dual monitors yet, but it works pretty well. GitHub - ericlay/desknamer
Also my personal dotfiles from my main machine. Nothing super cool, except the rofi menu. GitHub - ericlay/Bspwmdotfiles: Dot files from my Manjaro-bspwm set up
1 Like
Thank you. Nvidia troubleshooting page seems pretty useful.
I never thought about naming desktops and this script is really cool.
My dotfiles are also usually plain simple but I like to add cool parts from others’ dotfiles. Thanks for sharing.
1 Like
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.