Skip to content
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

Closed
svalaskevicius opened this issue Mar 18, 2024 · 15 comments
Closed

waybar is not shown sometimes on master branch #8075

svalaskevicius opened this issue Mar 18, 2024 · 15 comments
Labels
bug Not working as intended

Comments

@svalaskevicius
Copy link

svalaskevicius commented Mar 18, 2024

  • Sway Version:

    • branch based on master commit 23389eb
  • Configuration File:
    relevant bit:

bar bar1 {
    id bar1
    swaybar_command waybar -b bar1
    mode hide
    modifier $mod
}

exec waybar -b bar1
  • Description:

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.

@svalaskevicius svalaskevicius added the bug Not working as intended label Mar 18, 2024
@svalaskevicius
Copy link
Author

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

@svalaskevicius
Copy link
Author

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)

@Nefsen402
Copy link
Member

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.

@svalaskevicius
Copy link
Author

sure, what should I use to record the screen / what other info can I provide?

@svalaskevicius
Copy link
Author

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

@svalaskevicius
Copy link
Author

also, it doesnt happen all the time - but very frequently. especially after:

  1. hold mod - waybar appears
  2. press number to switch workspace
  3. release mod - waybar disappears, with black background, until the underlying window invokes a repaint

@Nefsen402
Copy link
Member

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?

@svalaskevicius
Copy link
Author

svalaskevicius commented Jul 30, 2024

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 - 1.9-5

waybar - I'm on arch - so it's gonna be 0.10.4-1 (not at that pc atm to check for sure but it's all up to date and that's the current version)

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 :)

@svalaskevicius
Copy link
Author

right, I can reproduce in a nested sway too, attaching a screen recording:

sway-bg-bug.mp4

@svalaskevicius
Copy link
Author

no idea why is github/firefox saying that the file is corrupt

wget 'https://github.com/user-attachments/assets/a93c74eb-05ba-48a4-b038-a88218052982'
mv a93c74eb-05ba-48a4-b038-a88218052982 aa.mp4    

vlc plays it ok.. it was recorded with wf-recorder

@Nefsen402
Copy link
Member

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.

@Nefsen402
Copy link
Member

Thanks, I can reproduce.

@Nefsen402 Nefsen402 added this to the 1.10 milestone Jul 31, 2024
@Nefsen402
Copy link
Member

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. WLR_SCENE_DISABLE_VISIBILITY=1 doesn't work because that only disables one optimization. We have a second optimization that will set the blend mode to NONE if the surface is supposed to be opaque.

@Nefsen402
Copy link
Member

Opened an issue here: Alexays/Waybar#3492

@svalaskevicius
Copy link
Author

Thanks for debugging this and finding the cause so quickly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Not working as intended
Development

No branches or pull requests

2 participants