Bug 335617 - Windows with aspect ratio hints different from screen aspect won't start fullscreen
Summary: Windows with aspect ratio hints different from screen aspect won't start full...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: general (show other bugs)
Version: 4.11.9
Platform: Archlinux Packages Linux
: NOR normal with 2 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/118...
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-30 23:31 UTC by Philip Sequeira
Modified: 2014-07-12 18:10 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.11.11
thomas.luebking: Decision-Required+
thomas.luebking: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Sequeira 2014-05-30 23:31:07 UTC
If I play a video with mpv that has an aspect ratio different from that of my display, and set it to start in fullscreen mode, it doesn't. It works fine with videos that match the screen aspect ratio, and it also works if I enter fullscreen mode after the window has been created.

This started after a recent change in mpv that sets fullscreen before mapping the window: https://github.com/mpv-player/mpv/commit/7ad8c5ff3352a6ae775ce12b2473aa7cf499cb2a
It is not yet in any release versions of mpv.

I reported it to mpv, but it was determined there that this was a problem with KWin.
mpv bug: https://github.com/mpv-player/mpv/issues/821

Reproducible: Always

Steps to Reproduce:
1. Run a build of mpv after the specified commit with --fullscreen on a video with aspect ratio different than that of the screen (or, should happen with any program that sets _NET_WM_STATE to _NET_WM_STATE_FULLSCREEN before mapping the window and sets aspect hints different than the display's aspect ratio)
Actual Results:  
The window is created as a normal (non-fullscreen) window

Expected Results:  
The window is created fullscreen

I saw https://bugs.kde.org/show_bug.cgi?id=86948, but that involved changing aspect hints on an already-fullscreen window, whereas this one involves setting both beforehand, so I thought it'd be better to create a new bug. Still, possibly related.
Comment 1 Thomas Lübking 2014-05-31 07:25:56 UTC
the window probably still has size constraints (the aspect ratio) when requesting to be mapped, thus kwin denies "isFullScreenable()", assuming the window (video) would get a wrong aspect - i assume those are withdrawn when the window gets fullscreened at runtime (and mpv adds black borders)

leaving open, kwin could ignore geo restrictions on mapping to rank the clients fullscreen request (state can be assumed to come from there) stronger than the aspect request.
Comment 2 nfxjfg 2014-05-31 15:33:48 UTC
I don't think mpv removes the aspect size hints (it always sets PAspect when calling XSetWMNormalHints() -  unless mpv is started with --no-keepaspect). But note that for fullscreening after map, a _NET_WM_STATE message is sent to toggle the state. And reportedly, fullscreening works after the window was created.
Comment 3 Thomas Lübking 2014-05-31 18:24:43 UTC
Status quo:
KWin applies fullscreen mode for client messages unconditionally, but on mapping "isFullScreenable()" is tested (ever since), which will return false since fixing bug #324733

We should pick one behavior.
Since both hints can be assumed to come from the client (and the mapping state even more than the message) I'd vote for relaxing and removing the ::isFullScreenable() test on ::manage()

Users still won't be offered to fullscreen windows w/ fixed aspects (since it's not certain whether the client can deal with that in a sane way) but the client can request the state at runtime AND initially.
Comment 4 nfxjfg 2014-05-31 18:49:16 UTC
I'm not sure what's this about forcing aspect in fullscreen - obviously the client doesn't expect that the aspect hints are honored when the client requests going into fullscreen.
Comment 5 Thomas Lübking 2014-05-31 18:59:59 UTC
The user can move _any_ window to fullscreen by context menu or KWin shortcut.

The check on ::manage() predates the git history (there was a branch change in early 4.0 times) - I don't know why it's there (but not on the client message response)

The manage code by this also doubles the rule check (breaking the "apply initially" condition), so I assume it's cruft (the code could date back to 1998 when there was no _NET_WM_STATE ;-)
Comment 6 Martin Flöser 2014-06-01 06:37:44 UTC
> Since both hints can be assumed to come from the client (and the mapping
> state even more than the message) I'd vote for relaxing and removing the
> ::isFullScreenable() test on ::manage()

"The Window Manager SHOULD honor _NET_WM_STATE whenever a withdrawn window 
requests to be mapped."

sounds to me like we need to honor it.

> The check on ::manage() predates the git history (there was a branch change
> in early 4.0 times) - I don't know why it's there (but not on the client
> message response)

one can get past that point by nice combinations of git log and blame, but I 
wouldn't be surprised if it goes back to initial commit
Comment 7 Thomas Lübking 2014-07-09 16:04:42 UTC
Git commit 43229afee9fac4303e3d280ea63f96f034b3ffb5 by Thomas Lübking.
Committed on 05/06/2014 at 18:23.
Pushed by luebking into branch 'KDE/4.11'.

allow FS mapping of geometry restricted windows

and copy isSpecialWindow() check as rulebook input
to setFullscreen()

Client::isFullScreenable() checks:
* fullscreen rule
* fullscreen_hack (-> for normal windows)
* geometry restrictions
* special window

Client::manage() for fullscreeining checks:
* fullscreen rule (with correct "initial" parameter)
* fullscreen_hack

-> this breaks the fullscreen rule for geometry restricted windows
and causes inconsistent behavior between client requests at runtime
(which do not test ::isFullScreenable()) and on mapping.

Otoh, the specialWindow() protection should apply generally - those
kind of windows should not be fullscreened since the user can not
exit this state via kwin for them - and there's hardly a good reason
for them to be fullscreen, esp. not to enter that state at runtime

REVIEW: 118442
FIXED-IN: 4.11.12

M  +1    -1    kwin/geometry.cpp
M  +1    -1    kwin/manage.cpp

http://commits.kde.org/kde-workspace/43229afee9fac4303e3d280ea63f96f034b3ffb5
Comment 8 Martin Flöser 2014-07-10 11:42:45 UTC
Git commit 75a298a4fbea8ec8dccd2e78aaa5ecc6f830846f by Martin Gräßlin, on behalf of Thomas Lübking.
Committed on 05/06/2014 at 18:23.
Pushed by graesslin into branch 'master'.

allow FS mapping of geometry restricted windows

and copy isSpecialWindow() check as rulebook input
to setFullscreen()

Client::isFullScreenable() checks:
* fullscreen rule
* fullscreen_hack (-> for normal windows)
* geometry restrictions
* special window

Client::manage() for fullscreeining checks:
* fullscreen rule (with correct "initial" parameter)
* fullscreen_hack

-> this breaks the fullscreen rule for geometry restricted windows
and causes inconsistent behavior between client requests at runtime
(which do not test ::isFullScreenable()) and on mapping.

Otoh, the specialWindow() protection should apply generally - those
kind of windows should not be fullscreened since the user can not
exit this state via kwin for them - and there's hardly a good reason
for them to be fullscreen, esp. not to enter that state at runtime

REVIEW: 118442

Cherry-picked from kde-workspace
43229afee9fac4303e3d280ea63f96f034b3ffb5

M  +1    -1    geometry.cpp
M  +1    -1    manage.cpp

http://commits.kde.org/kwin/75a298a4fbea8ec8dccd2e78aaa5ecc6f830846f