I actually don’t know what xdg-su is for but there was a problem yay updating so I had to uninstalled it. If it’s insecure I should keep it this way anyway.
For picom, I’m suspecting on both autostart and feh. If I find anything I’ll write here.
I fixed the picom issue with removing the parts about Intel graphics from autostart file. (I have Nvidia)
The topic can stay open for now since I’m not 100% sure.
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.
@Mitsukuni
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.
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.
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.
@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?
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.
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