-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
waybar is not shown sometimes on master branch #8075
Comments
forgot to add - swaybar is working ok with regards to this behaviour. so my assumption was that this is related to rendering the top shell layer. but I wasn't able to find the fault in the short time I had |
update from commit 4d4c88f - waybar is showing now, but the region is not repainted after mod key is released and waybar is hidden - that region is black, until the underlying window invalidates it or parts of it (then it repaints parts) |
I cannot reproduce this issue even when 4d4c88f was reverted on my local branch. I think there might me more to your configuration file? It sounds like the new symptoms have something to do with damage tracking, which at this point is unlikely since the renderer rewrite of sway. A demo video and a list of steps to reproduce would help. |
sure, what should I use to record the screen / what other info can I provide? |
my cfgs are also https://github.com/svalaskevicius/dotfiles/blob/gen-2024/.config/sway/config except the hide lone titlebar flag which should be commented out on this commit there is also waybar config in a nearby file |
also, it doesnt happen all the time - but very frequently. especially after:
|
Yeah, I've switched workspaces many times in my testing and have not seen it go wrong once. I am testing on the wayland backend with a nested session, but the backend should have nothing to do with this error. What kind of hardware are you running? Maybe it's a driver problem causing the screen not to repaint correctly? What version of waybar? |
sorry I missed the question. hardware - amd graphics card, but no other effects like that so I doubt it could be it, also an older sway version works fine (the one from arch packages - waybar - I'm on arch - so it's gonna be hmm I haven't tested in a nested session - can do that later in the evening, can also try recording video - if I find a screen recorder :) |
right, I can reproduce in a nested sway too, attaching a screen recording: sway-bg-bug.mp4 |
no idea why is github/firefox saying that the file is corrupt
vlc plays it ok.. it was recorded with |
Yeah, I don't know what going on with firefox and some video files. It's been bugged like that since forever. The video was very helpful thank you, it looks like this might be more to do with the waybar configuration than anything else. You have an opaque background, so more scene optimizations are trying to kick in. The issue can probably be worked around with the WLR_SCENE_DISABLE_VISIBILITY=1 in the env. |
Thanks, I can reproduce. |
This is a waybar bug. When waybar is trying to show/hide when pressing the mod key, it doesn't unmap the surface, it instead commits a completely transparent buffer. However, waybar does not update the transparency status of the buffer and still claims it's opaque. |
Opened an issue here: Alexays/Waybar#3492 |
Thanks for debugging this and finding the cause so quickly! |
Sway Version:
Configuration File:
relevant bit:
when waybar is configured to be shown only on $mod key press, it fails to appear after a window is created in that workspace.
switching to another workspace and hitting the $mod summons waybar as expected. even if I switch back to the original workspace, waybar is still shown while I keep $mod pressed. pressing it again does not show waybar in this workspace. no logs nor errors are reported when the key is pressed.
The text was updated successfully, but these errors were encountered: