Created attachment 1015801 [details] see extra left and right border, as well as the occasional white line for three mplayer windows. Description of problem: Neither gnome-shell nor mutter process PAspect in XSetWMNormalHints() correctly. The issue was first noticed as part of xv video corruption (https://bugs.freedesktop.org/show_bug.cgi?id=87455#c1) where there are extra black borders on both left and right, and the occasional white lines at either edge, but turn out to be separate. I tried modifying mplayer (https://bugs.freedesktop.org/show_bug.cgi?id=87455#c8) and found that if I comment out the PAspect line near line 1000 of libvo/x11_common.c for XSetWMNormalHints(): //vo_hint.flags |= PAspect; ... XSetWMNormalHints(mDisplay, vo_window, &vo_hint); The left-right black border for mplayer would go away. That indicates PAspect is not being processed correctly in XSetWMNormalHints(). For some strange reasons, gnome-shell or mutter insist on changing the video window from the correct ones of 832x468 -> 843x447, 720x404 -> 731x383 , 322x240 -> 334x222 repectively, thus creating some black borders on either side, when the input is already exact and correct and no-resizing is needed. The definite proof is that if I do "fvwm --replace &", I can get the video window to go without borders. I can switch back and forth with "fvwm --replace &", "gnome-shell --replace &" and "gnome-shell --mode=classic --replace&" and "mutter --replace &" and change the windows manager on the fly to get correct or broken behavior. This seems to suggest clutter is the problem. Version-Release number of selected component (if applicable): clutter-1.20.0-1.fc21.x86_64 mutter-3.14.4-1.fc21.x86_64 gnome-shell-3.14.4-2.fc21.x86_64 How reproducible: always Steps to Reproduce: 1. trying playing any of the example videos attached to https://bugs.freedesktop.org/show_bug.cgi?id=87455 with mplayer 2. 3. Actual results: Black border on either side of the playback area. Expected results: The window exactly fits the playback area. Additional info: As I say, I can switch to fvwm with "fvwm --replace &" to get the correct behavior (and back to the broken behavior under mutter/gnome-shell with "mutter/gnome-shell --replace &") Note also https://bugs.freedesktop.org/show_bug.cgi?id=87455 itself and the downstream backport bug here at https://bugzilla.redhat.com/show_bug.cgi?id=1213010
That's a bug in mutter fixed upstream[0] in 3.16 [0] https://git.gnome.org/browse/mutter/commit?id=cb66ab5a87251b21
(In reply to Florian Müllner from comment #1) > That's a bug in mutter fixed upstream[0] in 3.16 > > [0] https://git.gnome.org/browse/mutter/commit?id=cb66ab5a87251b21 Thanks - I exported the patch with git format-patch, downloaded the mutter-3.14.4-1.fc21 src rpm and modified it and rebuilding it with the patch, the patch applies cleanly. Then did gnome-shell --mode=classic --replace & , and verified that the commit does address the problem. Please create 3.14.4-2.fc21 or as appropriate.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
fixed upstream as in comments above and no longer an issue with current release.