Fresh installation, some parts broken after the update

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.

Thanks for the replies.

1 Like

It used to be in the Manjaro repos, but was dropped awhile ago.

You can remove that folder like this:

sudo rm -rf /home/mb/.cache/yay/xdg-su/pkg

sudo rm -rf /home/mb/.cache/yay/xdg-su/pkg

Thanks.

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.

2 Likes

That sounds like a relic from the time when I was maintaining bspwm edition. Let’s take it out of the default configuration.

1 Like

I feel like I was a little helpful. :slight_smile:

1 Like

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.

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

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.

@Mitsukuni @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. :slight_smile:

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.