Bug 1025391

Created attachment 817962 [details]
control-center is oversized ... can't fit into screen

Created attachment 820409 [details]
monitor-edid results

I'm not sure that (Null)-4 actually means what you think it means. I don't believe it has anything to do with physical size.

Can you please post Xorg.0.log and compare the output of monitor-edid in the 'working' case? What actual resolution is being used on the display?

At a *guess* I'd say the new hiDPI stuff is kicking in, inappropriately.

Created attachment 826075 [details]
Xorg.0.log

Per Xorg.0.log it seems to detect the monitor just fine and set the mode to 1024x768:

[    19.476] (II) RADEON(0): Output VGA-0 using initial mode 1024x768 +0+0 

which looks right. So yeah, my hidpi guess is my best guess right now. I do notice this:

[    19.401] (II) RADEON(0): Supported detailed timing:
[    19.401] (II) RADEON(0): clock: 65.0 MHz   Image Size:  32 x 86 mm

I believe those values are meant to represent the physical size of the screen, and they're clearly not correct - they're much too small. That could certainly cause the hidpi stuff to kick in, if those values are being used to calculate the display's DPI.

Emmanuele, do you think I'm on the right track here?

the high dpi code should only be enabled if the resolution detected leads to (2 * 96) DPI in both directions, i.e. the resolution divided by the display size is greater than the limit above:

  dpi_x = width_px / (width_mm / 25.4);
  dpi_y = height_px / (height_mm / 25.4);
  if (dpi_x > 192 && dpi_y > 192)
    window_scale = 2;

(from gnome-settings-daemon)

this only happens if the X server is telling us that the display has a non-zero size. monitor-edid seems to be sending 0x0mm, but the X server is sending 32x86 mm. clearly both are pretty much wrong anyway (unless 15" diagonal is 8 by 3 centimeters in size, in which case the display has a non-euclidean geometry from the dead city of R'lyeh).

doing some calculation, it seems that you're right: the DPI is greater then (2 * 96) in both directions, which triggers the euristic for toggling the high DPI code.

you can explicitly change the setting using GSettings:

  gsettings set org.gnome.desktop.interface scaling-factor 1

but I guess that the euristic will need some refinement. this should be a bug opened upstream against gnome-settings-daemon.

"but I guess that the euristic will need some refinement"

I know we've lost good people down that rabbit hole before ;) I think it'll be quite difficult to come up with a heuristic that catches all 'the display is lying to us' cases, especially if we don't just decide not to care about phones/small tablets and throw out anything under 6", for instance. But anyway, you might want to ask around and find out who it was who tried to deal with bogus EDIDs in the days when GNOME tried to respect the X-supplied DPI and not just whack it to 96x96.

(In reply to Adam Williamson from comment #8)
> "but I guess that the euristic will need some refinement"
> 
> I know we've lost good people down that rabbit hole before ;) I think it'll
> be quite difficult to come up with a heuristic that catches all 'the display
> is lying to us' cases, especially if we don't just decide not to care about
> phones/small tablets and throw out anything under 6", for instance.

anything with a high DPI display will have a resolution bigger than 2000px in either directions. this is the reported resolution of the display: the UI then adapts to that size by scaling everything by 2, so that the perceived resolution is halved, but the underlying resolution stays at the same size.

> But
> anyway, you might want to ask around and find out who it was who tried to
> deal with bogus EDIDs in the days when GNOME tried to respect the X-supplied
> DPI and not just whack it to 96x96.

GNOME never really dealt with that at all: it was all inside X. we just took the resolution and the size of the glass and computed the DPI out of it, just like we do now to get the scaling factor.

one option is to amend the scaling factor heuristic to ignore resolutions smaller than 1920x1080 regardless of the reported size of the glass; full HD displays with high DPI are not really common, and if so their resolution would be 3840x2160.

"anything with a high DPI display will have a resolution bigger than 2000px in either directions"

Um. I'm not sure that's correct. Consider a current 'superphone': 1920x1080 at 5". That's 440dpi - certainly 'hidpi'.

As I said, if you decide you can safely exempt small-screened devices from the hidpi mechanism entirely (if we're going to be doing some other kind of special rendering for those), then a simple heuristic like the one you suggest (just ignore anything under 2000px) could help a lot.

There are some annoying corner cases though (aren't there always)? - Asus makes a laptop at 11", 1920x1080, the UX21a:

http://www.bestbuy.com/site/asus-11-6-34-laptop-4gb-memory-128gb-solid-state-drive-radiant-silver/6869272.p?id=1218810051686&skuId=6869272

1920x1080 at 11" is 189.91dpi - very close to a perfect 2x96.

again: the reported resolution has nothing to do with the perceived one. 1920x1080 reported resolution, even if it's 400+ DPI, does not imply scaling the entire desktop by a factor of 2. that should only happen if the reported resolution can be halved and still have a decent perceived resolution, i.e. the 15" rMBP has a reported resolution of 2880x1800, and if you scale it by 2 you get 1440x900 of perceived resolution, which is still pretty much reasonable (and the intent of the manufacturer when creating the display).

so you really don't want the perceived resolution of a 189 DPI, 1920x1080 display to be halved at 960x540, because that would be impressively dumb: for one, I doubt any application would ever cope with that height (in the same way we don't cope with NTSC/PAL sizes either).

if the display supports full HD then I want all that full HD goodness for my videos and for my desktop — otherwise app developers would have to determine the size of the display and undo any scaling factor the tool kits impose on them, thus breaking the It Should Just Work™ approach.

Created attachment 832793 [details]
Xorg

Created attachment 832794 [details]
monitor-edid

hi everybody

I get this same problem

BIOS Information
        Vendor: American Megatrends Inc.
        Version: V2.2
        Release Date: 07/10/2013
Base Board Information
        Manufacturer: MSI
        Product Name: FM2-A75IA-E53 (MS-7792)
        Version: 1.0
Version: AMD A10-5700 APU with Radeon(tm) HD Graphics   

Monitor is Panasonic TX-L37DT30B and in gnome's display setting I get 32" instead of 37" and my gnome desktop crosses outsize of the physical monitor screen.

attached pe.*

regards

my Xorg.log says:

[     5.383] (II) RADEON(0): clock: 74.2 MHz   Image Size:  698 x 392 mm
[     5.383] (II) RADEON(0): h_active: 1920  h_sync: 2448  h_sync_end 2492 h_blank_end 2640 h_border: 0
[     5.383] (II) RADEON(0): v_active: 540  v_sync: 542  v_sync_end 547 v_blanking: 562 v_border: 0


but it should be

94 cm (diagonal)
819 mm (W) × 460 mm (H)

I was curious why monitor-edid and Xorg logs differed, but ajax tells me:

<ajax> so yeah, there's two places you can get a wild-ass guess about physical size out of edid
<ajax> one is in the basic parameters chunk and that's measured in cm
<ajax> and one is per-detailed-timing measured in mm
<mclasen> https://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html

So this is another case of 'monitor lying to us', though, and it's basically impossible for us to do anything about your case: your display is reporting a size that's incorrect, but very plausible. I can't really see a way we can know that it's wrong. For this hidpi problem, Emmanuele's trick of not using hidpi unless the display is 2000px in at least one dimension should fix it; but anything else that relies on the Xorg reported screen size is going to be wrong, and we can't really help you.

notting points out that, given your display is also telling us it's 32" big, it sounds a lot like Panasonic stuck an entry written for a 32" TV in the firmware of your 37" TV. If you want something to put in Youtube's comedy section, call their customer support line, complain about it, and see exactly how far it gets you :/

I've just discovered this bug as well, and had to revert back to Fedora 19.  Fedora 20 thinks my 40" Samsung TV is only a 7" device, and everything is huge.  The monitor-edid output was this:

-----------------------------------------------------------
Name: SAMSUNG
EISA ID: SAM094e
EDID version: 1.3
EDID extension blocks: 1
Screen size: 89.0 cm x 50.0 cm (40.19 inches, aspect ratio 16/9 = 1.78)
Gamma: 2.2
Digital signal
Max video bandwidth: 230 MHz

	HorizSync 15-81
	VertRefresh 24-75

	# Monitor preferred modeline (60.0 Hz vsync, 67.5 kHz hsync, ratio 16/9, 54 dpi)
	ModeLine "1920x1080" 148.5 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
-----------------------------------------------------------

However, when I launched "Displays" from the settings, it was listing my primary display as Samsung Electric Company 7".

This happened with the downloaded LiveCD, as well as the original install I performed a few weeks back.

Danny: it's not "Fedora 20 thinks", really, it's "your monitor is telling us". If you check Fedora 19 it likely says exactly the same thing, but F19 didn't have the hidpi support, so it didn't cause a visible problem.

Comment #7 gives the workaround for this, it's pretty simple. Maybe I should add a commonbugs note.

(In reply to Adam Williamson from comment #19)

> Comment #7 gives the workaround for this, it's pretty simple. Maybe I should
> add a commonbugs note.

which workaround?  This? :

> you can explicitly change the setting using GSettings:
> gsettings set org.gnome.desktop.interface scaling-factor 1

That *didnt* work for for me.  Actually, that's the default setting, and was never adjusted initially.  Setting it to 0.5 gave the desired resolution but lots of other UI text elements (GTK) became illegible.  Two monitors and their associated system units are now sitting idle because of this. Its worrisome especially since those monitors displayed properly on previous Fedora releases.

Emmanuele: has the dconf key changed or something? See c#20

(In reply to Adam Williamson from comment #21)
> Emmanuele: has the dconf key changed or something? See c#20

no, it hasn't changed, as far as I know, so this could be an indication of another bug entirely - or of personal preference for smaller font sizes.

In that case - onyeibo, can you provide screenshots of exactly what you're talking about? The previous release rendering that you think is 'right', and the way F20 does it both with that set to 1 and with it set to 0.5? Thanks!

Aaaaah, I'm afraid that's not going to be possible.  The monitors were sold a few days ago.  I replaced them with used Dell monitors (F20 seems happier with those) and that's less worries for me.

IIRC, https://bugzilla.redhat.com/attachment.cgi?id=817962
The above was the monitor at "1".  At "0.5", the gnome-shell adjusted well but Metacity (nautilus et al) remained oversized.  Some text didn't scale well too.

Same problem with my Samsung SyncMaster T240HD on Fedora 20. "It is detect as Samsung Electric Company 7" although it is an 24" display. Everything is displayed too hugh.

Bug appeared when switching back from propretary ATI drivers to open source drivers. Modes seem to be detected just fine. Haven't had any issues with this monitor + GPU under Fedora 19.

"inxi -gx:":
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Barts XT [Radeon HD 6870] bus-ID: 01:00.0 
           Fedora X.org: 1.14.4 drivers: ati,radeon Resolution: 1920x1200 
           GLX Renderer: Gallium 0.4 on AMD BARTS GLX Version: 3.0 Mesa 9.2.5 Direct Rendering: Yes

"uname -a":
 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Xorg.0.log: 
[  1021.898] (II) Quirked EDID physical size to 0x0 cm
[  1021.898] (II) RADEON(0): EDID vendor "SAM", prod id 1063
[  1021.898] (II) RADEON(0): Using hsync ranges from config file
[  1021.898] (II) RADEON(0): Using vrefresh ranges from config file
[  1021.898] (II) RADEON(0): Printing DDC gathered Modelines:

Created attachment 855681 [details]
Xorg.0.log

Added the Xorg.0.log. The monitor is connected using HDMI.

Created attachment 855682 [details]
Screen with initial scaling factor

gsettings get org.gnome.desktop.interface scaling-factor

gave ma a scaling factor of "0"

Created attachment 855683 [details]
Screen with scaling factor set to 1

Scaling factor set to 1

Is https://bugzilla.redhat.com/show_bug.cgi?id=1047152 about the same problem (42" TV treated as 7" screen with F20, worked fine with previous versions)?

*** Bug 1047152 has been marked as a duplicate of this bug. ***

Tomasz: yes.

Note, it's very unlikely that the monitor detection actually "worked fine with previous versions". If you go boot a Fedora 19 live image and check, I'll bet dollars to donuts it *also* sees the screen as a Samsung Electric Company 7". We get that data from the monitor: if the monitor lies to us, there is very little we can do about it.

What changed in Fedora 20 is the hidpi support got added to GTK+. Fedora 19 didn't try and do anything in particular with the information about the density of the screen, so you were unlikely to *notice* that the screen's EDID data was bogus, because it wouldn't lead to any visible consequences. With the hidpi support addition in F20, it does.

I need to go upstream and check on the status of Emmanuele's suggested fix in https://bugzilla.redhat.com/show_bug.cgi?id=1025391#c11 , and see if we can backport that to F20, as this seems to be hitting several people.

Looks like this has turned into rather a mess upstream :/

http://bugzilla.gnome.org/show_bug.cgi?id=712529

the hack of just disallowing scaling for resolutions lower than 1200 vertically (or something like that) seems to have been objected to on the basis that there are small tablets with 1920x1080 displays, and you might want hidpi scaling to kick in there.

apparently, the executive summary here is that display density is *still* a giant PITA.

Actually, what no one seems to have noticed is that the X server *already* has a list of monitor brands that are known to lie to it. Samsung TVs are in that list. The reason the X server reports 0x0 is specifically because it knows that Samsung monitors are lying. This bug has bit before, and was fixed by adding a "quirks" list.

Now gnome, in its infinite wisdom, has decided to ignore the X server, go out of its way to dig up the raw EDID info, and completely disregard the fact that X already knows it is bogus.

The only good way to fix this is to provide a convenient and easy way for users (who know a darn sight more than gnome knows) to edit their own EDID info and override what the lying hardware is saying. Of course, at one time we could just plug good numbers into an xorg.conf file, but now we have to edit proprietary format undocumented EDID binary blobs - things have improved so much since everyone decided it was such a good idea to utterly ignore xorg.conf.

(In reply to Adam Williamson from comment #31)
> Note, it's very unlikely that the monitor detection actually "worked fine
> with previous versions". If you go boot a Fedora 19 live image and check,
> I'll bet dollars to donuts it *also* sees the screen as a Samsung Electric
> Company 7". We get that data from the monitor: if the monitor lies to us,
> there is very little we can do about it.

Currently reverted back to Fedora 19, and with this install and going to Settings -> Displays, the TV is correctly listed as Samsung Electric Company 40", whereas Fedora 20 showed Samsung Electric Company 7"

Are there some other tests to verify this?  monitor-edid looks the same in Fedora 19 and 20

Tom: I really don't think that tone is warranted or appropriate. I don't know why you assume no-one has noticed that. Some of the people involved in this are the same people who were involved in the *last* go-round with DPI stuff, when the incomplete quirk list the X server has was developed.

But it *is* incomplete, so we can't just solve it for Samsung TVs and pretend everything's hunky dory. It seems pretty obvious from the upstream bug that the GNOME devs are working on this, and it's a difficult problem to solve particularly cleanly.

Danny: hum, that's weird. I wonder where the 7" / 40" thing comes from; I thought it was just reading an ident string out of the EDID data. Can you post the X logs for both?

Tom: "The only good way to fix this is to provide a convenient and easy way for users (who know a darn sight more than gnome knows) to edit their own EDID info and override what the lying hardware is saying"

oh, and that's not a good fix, it's a *terrible* fix. it relies on users knowing what EDID info is, that their EDID info is wrong, that the problem they're seeing is a consequence of their EDID information being wrong, and how they should change it to resolve the problem. If it comes down to that, we already lost.

> I wonder where the 7" / 40" thing comes from; I thought it was just reading an ident string out of the EDID data

Adam, as noted in #1047152, for my 42" TV:

# cat ./devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-3/edid | edid-decode  | grep size
Maximum image size: 89 cm x 50 cm

This is true, and that's where 42" comes from.

Yet xrandr shows:
HDMI3 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 160mm x 90mm

16cm x 9 cm gives 7"

(sorry for mixing units)

oh, it actually calculates the size? heh. Like I said, I always just figured it was reading that out of the EDID.

And 16x9 cm is not a real size but point d) from: https://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html
Link from https://bugzilla.gnome.org/show_bug.cgi?id=709859

And I've discovered what is wrong with fixing the scaling factor with gsettings: That scaling factor also gets applied when I run a remote NX session. Now all the gtk apps in the NX display have microscopically small text. I'm definitely going to have to attack the EDID info.

>Tom: "The only good way to fix this is to provide a convenient and easy way
>for users (who know a darn sight more than gnome knows) to edit their own
>EDID info and override what the lying hardware is saying"
>
>oh, and that's not a good fix, it's a *terrible* fix. it relies on users
>knowing what EDID info is, that their EDID info is wrong, that the problem
>they're seeing is a consequence of their EDID information being wrong, and
>how they should change it to resolve the problem. If it comes down to
>that, we already lost.

No, it requires users to look at their screen, say "Good God! What the hell is that?" and run to the control center display settings. They don't need to know that the things they are overriding in the display setting work by modifying the EDID info.

>But it *is* incomplete, so we can't just solve it for Samsung TVs and pretend >everything's hunky dory. It seems pretty obvious from the upstream bug that the >GNOME devs are working on this, and it's a difficult problem to solve >particularly cleanly.

Its not a difficult problem to solve, its an impossible problem to solve. The monitor is lying. It can lie any number of different ways. New monitors can invent new ways to lie. No heuristic or wishful thinking on the part of gnome devs can fix that. A human with eyes sitting in front of the monitor can fix it if given half a chance. If allowed to "phone home" one user's corrections could even be picked up by other users so fewer and fewer people have to manually fix things (especially if multiple users keep reporting the exact same overrides for the exact same monitor model).

What is the obsession with preventing poor old mentally feeble users from setting anything? If users are too incompetent to say "I have a 47" TV, not a 7" TV" which actually lets them see the screen, then they are too incompetent to be using the computer for anything at all.

"They don't need to know that the things they are overriding in the display setting work by modifying the EDID info."

So, um, why would you prefer the odd and indirect method of 'overriding the EDID info' to simply having an override for the display scaling factor, as I've already requested at https://bugzilla.gnome.org/show_bug.cgi?id=723624 ?

Because the scaling factor is applied on a per-user basis. When I connect
remotely (as in an NX session), I also get the same scaling factor and now instead of being too large, everything is too small. Anything that tries to fix the screwed up data independent of the monitor will wind up cascading screwups in different places.

I have actually managed to get a fixed EDID installed and it works perfectly now that I've reverted the scaling factor.

As long as I'm editing EDID, the next thing I need to figure out is where to change it to convince the Intel video driver I can do full range color so I don't have to see my monitor through a gauze film while booting...

Booted into Fedora 20 Live USB, and tried the:
gsettings set org.gnome.desktop.interface scaling-factor 1
No changes at all, issue remains.

Danny: did you run it as user or as root? It should be as user.

(In reply to Adam Williamson from comment #45)
> Danny: did you run it as user or as root? It should be as user.

Yes, as the Live user, not as root.  Even tried to ALT+F2 -> r it.  Then tried to to kill gdm and tried the again, still no go.

Me too. Just threw F20 onto a spare machine for an HTPC, connected via HDMI to a 55" Samsung TV. Display settings indeed list it as being 7".

Since no one has explicitly pointed it out, here's the complete quick easy workaround so you can get on with your life:

gsettings set org.gnome.desktop.interface scaling-factor 1
gsettings set org.gnome.desktop.interface text-scaling-factor 1.5

You need both for complete sanity.

If gnome-tweak-tool let me adjust 'scaling-factor' as well as 'text-scaling-factor' I would not have even needed to open a shell, and would have saved me some time googling for a workaround.

What we really need is a option that tells gnome to believe the dadgum DPI setting the X server already provides rather than going out of its way to calculate its own DPI based on incorrect information.

I fixed it on my Samsung TV (hopefully permanently) by providing my own modified EDID on the kernel command like with the actual correct values.

Oh and you probably also want:

gsettings set org.gnome.desktop.interface cursor-size 64

We do not need another configuration option, we do need GNOME to do the right thing. What we see is the point d) of https://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html :

"d) Glass size could be a direct encoding of the aspect ratio.  Base EDID
doesn't condone this behaviour, but the CEA spec (to which all HDMI
monitors must conform) does allow-but-not-require it, which means your
1920x1080 TV could claim to be 16 "cm" by 9 "cm"."

So Samsung TV encode 16:9 aspect ratio, which GNOME treats as real dimensions – that where 7” comes from. Previously this case was apparently treated correctly (by X11). Right now it's taken literally by GNOME.

(In reply to Tomasz Torcz from comment #50)
> We do not need another configuration option, we do need GNOME to do the
> right thing. 


I have to agree to Tomasz.  Even with the specific gsettings above, which I finally retested and confirmed they are "working", the are still some side effects that cause the desktop to not act as clean as Fedora 19, so...again...had to switch back.  Anyone know if this will be properly fixed in upcoming updates?

"the are still some side effects that cause the desktop to not act as clean as Fedora 19"

Please understand that saying this is useless. No-one reading this bug report is a mindreader or possessed of superpowers; we can't see or divine what it is that you are seeing, and therefore we cannot fix it. What are these side effects? In what way is it "not as clean as Fedora 19"?

"Anyone know if this will be properly fixed in upcoming updates?"

We can't properly fix a problem if we don't know what it is.

Created attachment 907878 [details]
danny_Fedora19_Xorg.0.log

Created attachment 907879 [details]
danny_Fedora20_Xorg.0.log

Created attachment 907880 [details]
danny_Fedora19_desktop.png

Created attachment 907881 [details]
danny_Fedora20_desktop.png

(In reply to Adam Williamson from comment #52)
> Please understand that saying this is useless. 

Sorry for my useless comment.  After reading the posts above from Tomasz and Tom and Peter from https://bugzilla.gnome.org/show_bug.cgi?id=709859 I was under the impression that the "side effects" were a known thing, and that even though Gnome reported this as RESOLVED FIXED, people were still having to use custom EDIDs to get things working correctly.

I downloaded the latest Fedora 20 Live and ran the following settings:
gsettings set org.gnome.desktop.interface scaling-factor 1
gsettings set org.gnome.desktop.interface text-scaling-factor 1.5
gsettings set org.gnome.desktop.interface cursor-size 64

I tried adjusting those with 1, 1.5, .5, etc. The results were still larger icons, larger fonts, resolution looks like 800x600, etc.  I have attached screen shots and Xorg logs showing the difference:
danny_Fedora19_Xorg.0.log
danny_Fedora20_Xorg.0.log
danny_Fedora19_desktop.png
danny_Fedora20_desktop.png

thanks, that does make it clearer what you're talking about. 'text-scaling-factor 1.5' is effectively setting a DPI of 144 (96+48), though; that screenshot is more or less what I'd expect 134 DPI to look like. Can you provide a screenshot of scaling-factor and text-scaling-factor both set to 1?

(this is, in any case, not the same issue, so it should probably be filed separately...)

Created attachment 908797 [details]
danny_Fedora20_desktop_scaling1

(In reply to Adam Williamson from comment #58)
> Can you provide a screenshot of scaling-factor and text-scaling-factor
> both set to 1?

danny_Fedora20_desktop_scaling1.png uploaded.

Thanks, that is MUCH better.  Looks like I'll be kicking off the install today.  Thanks for all the help!

I got a 32" Samsung TV connected to my Fedora 20 (Dell Inspiron N5110) and I can see the following misbehaviour:
If I use just Laptop screen, everything is fine,
If I use just the TV screen, everything is fine,
If I use the screens to extend each other, everything is fine,
However;
If I try to duplicate my screens to see the same on the TV as on the laptop, than everything goes crazy on both displays, everything is superbig and there is not much space for anything.

As noted by Tomasz Torcz Samsung reported the Screen Size 16 cm x 9 cm Which is why it comes up with 7" display size. (I got the same Samsung Electrical Company 7")

I tried modifying the scaling factor to 1 but no success, What is unclear to me is that why Fedora 20 can handle the same displays nicely with extended desktop mode but it messes up with duplicate mode?

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 '20'.

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 20 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.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.