-
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
mako notifications stay "burnt in" until screen/region updates otherwise #6914
Comments
Does #6844 help? |
what would testing it entail? clone master, merge PR, build manually? do I need a git version of wlroots? |
Yeah, you need wlroots from git. You can also just pull in the source branch of the PR directly for now, I rebased recently so there shouldn't be conflicts with git wlroots. To test, just run mako and see if the "burn in" remains. |
I just came across this issue and I'm experiencing something similar, although not exactly the same behavior. Don't know if it's related, if it's not, I'll create a new issue 👍 VID_20220528_112311_01.mp4 |
Yes, it looks like in your video for me too sometimes. I think using a screen recorder as I did changes the effect slightly, you seem to have used an external camera. |
Closed by #6844. |
Please fill out the following:
Sway Version:
Debug Log:
Configuration File:
mako is launched via
systemctl --user start mako.service
(usually autostarts because enabled, but not in this minimal config)Description:
Originally opened at Notification "burnt in" until screen updates emersion/mako#418
Here is a video of the test case
for x in 1 2 3 4 5; do notify-send "test" "message $x"; done
:mako.mp4
As you can see, clicking to dismiss a notification makes the others move down, yet they also stay burnt in at their old position. It looks particularly weird if notifications have different heights.
Any update to the screen area will "flush" the lingering notification, that includes switching to (from?) the window behind it. Thus the issue mainly appears when there is no window open on the monitor, e.g. on boot or with a multi monitor setup. The interaction with the mouse cursor wiping the notifications away, while illustrating my point about updating the screen area, actually appears only during recording with
wf-recorder
- I can normally only get windows to clear them.Per the original issue, emersion said to try
sway -Ddamage=rerender
which did help work around the issue.My platform is arch's core/linux kernel (currently 5.16.16), mako 1.6-3, sway 1.7-2, wlroots 0.15.1-3, gdm 41.3-2.
The text was updated successfully, but these errors were encountered: