Border around full screen window visible on other monitors, only with "fs" option #1920
Comments
|
I'd say this is the window manager's fault. mpv doesn't attempt to remove borders when fullscreening, but it shouldn't need to do that. Fullscreening basically works by telling the window manager that the application wants to go fullscreen, and the WM takes care of resizing and positioning the window etc.. Also, the newest version is 0.9.1, not 0.8.3. But this probably doesn't change anything about this. |
|
You're right, if I replace Marco with Openbox (openbox --replace), the border disappears. Then I do marco --replace and it re-appears as it takes control of the full-screen window. I never thought of that. Well, it would still be sweet if it was possible to add a work-around: make it open full screen like it does when pressing "f", as that's supported correctly. But I will understand if you reject this. |
|
Well, I'm not sure why initial fullscreen switching would be different from fullscreen switching at runtime, but technically we do these differently. We want initial fullscreen switching to happen atomically when the window becomes visible, and we do this by setting the The way we handle the initial fullscreen state might not be completely standard. Maybe you can talk to the devs of your WM? |
It appears some WMs have a problem with out method of setting initial fullscreen mode. We assume that if the window's _NET_WM_STATE includes _NET_WM_STATE_FULLSCREEN before mapping the window, the WM will show it as fullscreen at mapped. EWMH doesn't say anything that this should work, although one could argue that it's implied. In any case, since it's not standard behavior without at least some doubt, it's probably a good idea to try the "old" method as well. Fortunately, it should be idempotent. See #1937, #1920.
|
I added a workaround, and hope this fixes it. It would still be nice if mate-desktop supported atomic fullscreening, though. |
ghost
closed this as It appears some WMs have a problem with out method of setting initial fullscreen mode. We assume that if the window's _NET_WM_STATE includes _NET_WM_STATE_FULLSCREEN before mapping the window, the WM will show it as fullscreen at mapped. EWMH doesn't say anything that this should work, although one could argue that it's implied. In any case, since it's not standard behavior without at least some doubt, it's probably a good idea to try the "old" method as well. Fortunately, it should be idempotent. See #1937, #1920. (cherry picked from commit a4f3df5)
|
I know it's late but I confirm: it actually helped! Thank you. (There's now a new minor issue with going out of full screen but unrelated to this fix imho.) |
|
Thanks for letting us know. |
|
This also fixes any compatibility issues I had between mpv's fullscreen mode and xmonad. (In the past, the problem was also that xmonad ignored fullscreen state changes that happened while the window wasn't mapped) |
Hi, I have "fs" option in my mpv.conf, but every time it starts in full screen mode, there's a 4 pixel border around it, visible on the display next to it. The border captures screen contents when MPV started and stays on top of programs on that screen (so I have trouble using scroll bar of a browser on the left screen :))
Pressing "f" twice to go to window mode and back to full screen fixes the problem.
Using "no-border" in the config also fixes the problem, but I prefer to have the border in window mode, just not full screen.
I thought maybe it depends on vo, so I've tried vo=vdpau, vo=opengl and vo=xv (last case ignored hwdec=vdpau). Nothing changed.
This happens whether or not I use "geometry" or "screen" setting to put it on a different screen. Whichever screen it starts on, I will see a border on the other, which disappears after double-f.
This behavior was here in 0.6/0.7, but I hoped 0.8 update will fix it. Now that 0.8.3 landed in Fedora repositories, I'm finally reporting it.
This is MATE+Marco, not compositing (probably important).
The text was updated successfully, but these errors were encountered: