Bug 1025391 - high DPI mode incorrectly engaged due to display detection issues
high DPI mode incorrectly engaged due to display detection issues
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon (Show other bugs)
20
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 1047152 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-31 11:11 EDT by Onyeibo
Modified: 2015-06-29 08:46 EDT (History)
27 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 08:46:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
login screen ... text is oversized (295.50 KB, image/png)
2013-10-31 11:11 EDT, Onyeibo
no flags Details
control-center is oversized ... can't fit into screen (293.86 KB, image/png)
2013-10-31 11:13 EDT, Onyeibo
no flags Details
monitor-edid results (97.13 KB, image/png)
2013-11-06 09:27 EST, Onyeibo
no flags Details
Xorg.0.log (40.95 KB, text/plain)
2013-11-19 08:45 EST, Onyeibo
no flags Details
Xorg (69.99 KB, text/plain)
2013-12-04 12:53 EST, lejeczek
no flags Details
monitor-edid (3.96 KB, text/plain)
2013-12-04 12:53 EST, lejeczek
no flags Details
Xorg.0.log (71.35 KB, text/x-log)
2014-01-26 09:11 EST, David Hildenbrand
no flags Details
Screen with initial scaling factor (851.97 KB, image/png)
2014-01-26 09:18 EST, David Hildenbrand
no flags Details
Screen with scaling factor set to 1 (1.88 MB, image/png)
2014-01-26 09:20 EST, David Hildenbrand
no flags Details
danny_Fedora19_Xorg.0.log (21.55 KB, text/plain)
2014-06-11 18:02 EDT, Danny
no flags Details
danny_Fedora20_Xorg.0.log (61.12 KB, text/plain)
2014-06-11 18:03 EDT, Danny
no flags Details
danny_Fedora19_desktop.png (763.60 KB, image/png)
2014-06-11 18:03 EDT, Danny
no flags Details
danny_Fedora20_desktop.png (467.66 KB, image/png)
2014-06-11 18:04 EDT, Danny
no flags Details
danny_Fedora20_desktop_scaling1 (682.79 KB, image/png)
2014-06-14 11:23 EDT, Danny
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 709859 None None None Never
GNOME Desktop 712529 None None None Never

  None (edit)
Description Onyeibo 2013-10-31 11:11:58 EDT
Created attachment 817961 [details]
login screen ... text is oversized

Description of problem:
After installation of F20, the user is presented with a login screen with grand/large texts (see attached images)

Version-Release number of selected component (if applicable):
1:3.10.1-1.fc20

How reproducible:
Constant (100%) with this particular monitor

Steps to Reproduce:
1. Install F20 on the machine having "Crystal View" monitor
2. Boot
3. You should be experiencing the dilemma at login screen 

Actual results:
As described above

Expected results:
A login screen (and other subsequent UI elements e.g.metacity, texts, gnome-shell) should display with right sizes

Additional info:
This is a regression.  Same machine & Monitor displays fine on F15 to F19.  At Control-Center (display), the monitor is listed as (Null)-4"
That is to say, "4-inch" monitor, whereas it is a 15" 4:3 monitor
Comment 1 Onyeibo 2013-10-31 11:13:46 EDT
Created attachment 817962 [details]
control-center is oversized ... can't fit into screen
Comment 2 Onyeibo 2013-11-06 09:27:05 EST
Created attachment 820409 [details]
monitor-edid results
Comment 3 Adam Williamson 2013-11-12 20:52:36 EST
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.
Comment 4 Onyeibo 2013-11-19 08:45:17 EST
Created attachment 826075 [details]
Xorg.0.log
Comment 5 Adam Williamson 2013-11-19 13:25:07 EST
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.
Comment 6 Adam Williamson 2013-11-19 13:26:10 EST
Emmanuele, do you think I'm on the right track here?
Comment 7 Emmanuele Bassi 2013-11-19 13:54:41 EST
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.
Comment 8 Adam Williamson 2013-11-19 14:01:40 EST
"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.
Comment 9 Emmanuele Bassi 2013-11-19 14:16:31 EST
(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.
Comment 10 Adam Williamson 2013-11-19 14:22:19 EST
"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.
Comment 11 Emmanuele Bassi 2013-11-19 14:41:08 EST
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.
Comment 12 lejeczek 2013-12-04 12:53:27 EST
Created attachment 832793 [details]
Xorg
Comment 13 lejeczek 2013-12-04 12:53:57 EST
Created attachment 832794 [details]
monitor-edid
Comment 14 lejeczek 2013-12-04 13:03:31 EST
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
Comment 15 lejeczek 2013-12-04 13:14:34 EST
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)
Comment 16 Adam Williamson 2013-12-04 15:07:09 EST
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.
Comment 17 Adam Williamson 2013-12-04 15:09:54 EST
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 :/
Comment 18 Danny 2014-01-11 16:46:18 EST
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.
Comment 19 Adam Williamson 2014-01-12 01:49:24 EST
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.
Comment 20 Onyeibo 2014-01-12 02:15:11 EST
(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.
Comment 21 Adam Williamson 2014-01-12 12:22:15 EST
Emmanuele: has the dconf key changed or something? See c#20
Comment 22 Emmanuele Bassi 2014-01-24 09:48:13 EST
(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.
Comment 23 Adam Williamson 2014-01-24 13:53:53 EST
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!
Comment 24 Onyeibo 2014-01-24 17:11:40 EST
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.
Comment 25 David Hildenbrand 2014-01-26 09:04:37 EST
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@60.0hz 
           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:
Comment 26 David Hildenbrand 2014-01-26 09:11:59 EST
Created attachment 855681 [details]
Xorg.0.log

Added the Xorg.0.log. The monitor is connected using HDMI.
Comment 27 David Hildenbrand 2014-01-26 09:18:16 EST
Created attachment 855682 [details]
Screen with initial scaling factor

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

gave ma a scaling factor of "0"
Comment 28 David Hildenbrand 2014-01-26 09:20:07 EST
Created attachment 855683 [details]
Screen with scaling factor set to 1

Scaling factor set to 1
Comment 29 Tomasz Torcz 2014-02-03 09:35:34 EST
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)?
Comment 30 Adam Williamson 2014-02-03 14:46:45 EST
*** Bug 1047152 has been marked as a duplicate of this bug. ***
Comment 31 Adam Williamson 2014-02-03 14:49:22 EST
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.
Comment 32 Adam Williamson 2014-02-03 15:34:22 EST
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.
Comment 33 Tom Horsley 2014-02-03 16:42:19 EST
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.
Comment 34 Danny 2014-02-03 17:30:04 EST
(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
Comment 35 Adam Williamson 2014-02-03 18:04:43 EST
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?
Comment 36 Adam Williamson 2014-02-03 18:05:50 EST
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.
Comment 37 Tomasz Torcz 2014-02-04 01:24:27 EST
> 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)
Comment 38 Adam Williamson 2014-02-04 01:30:10 EST
oh, it actually calculates the size? heh. Like I said, I always just figured it was reading that out of the EDID.
Comment 39 Tomasz Torcz 2014-02-04 01:34:36 EST
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
Comment 40 Tom Horsley 2014-02-11 07:55:15 EST
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.
Comment 41 Tom Horsley 2014-02-11 19:40:52 EST
>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.
Comment 42 Adam Williamson 2014-02-11 20:51:14 EST
"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 ?
Comment 43 Tom Horsley 2014-02-11 21:42:39 EST
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...
Comment 44 Danny 2014-03-30 09:37:47 EDT
Booted into Fedora 20 Live USB, and tried the:
gsettings set org.gnome.desktop.interface scaling-factor 1
No changes at all, issue remains.
Comment 45 Adam Williamson 2014-03-31 19:01:49 EDT
Danny: did you run it as user or as root? It should be as user.
Comment 46 Danny 2014-04-02 19:44:52 EDT
(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.
Comment 47 Callum Lerwick 2014-04-04 18:33:36 EDT
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.
Comment 48 Tom Horsley 2014-04-04 19:10:45 EDT
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.
Comment 49 Callum Lerwick 2014-04-04 19:20:28 EDT
Oh and you probably also want:

gsettings set org.gnome.desktop.interface cursor-size 64
Comment 50 Tomasz Torcz 2014-04-05 05:49:56 EDT
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.
Comment 51 Danny 2014-04-29 20:15:37 EDT
(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?
Comment 52 Adam Williamson 2014-04-29 20:56:49 EDT
"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.
Comment 53 Danny 2014-06-11 18:02:56 EDT
Created attachment 907878 [details]
danny_Fedora19_Xorg.0.log
Comment 54 Danny 2014-06-11 18:03:17 EDT
Created attachment 907879 [details]
danny_Fedora20_Xorg.0.log
Comment 55 Danny 2014-06-11 18:03:52 EDT
Created attachment 907880 [details]
danny_Fedora19_desktop.png
Comment 56 Danny 2014-06-11 18:04:22 EDT
Created attachment 907881 [details]
danny_Fedora20_desktop.png
Comment 57 Danny 2014-06-11 18:05:05 EDT
(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
Comment 58 Adam Williamson 2014-06-11 18:50:16 EDT
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...)
Comment 59 Danny 2014-06-14 11:23:46 EDT
Created attachment 908797 [details]
danny_Fedora20_desktop_scaling1
Comment 60 Danny 2014-06-14 11:25:09 EDT
(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!
Comment 61 Elemer Gazda 2014-11-25 15:38:13 EST
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?
Comment 62 Fedora End Of Life 2015-05-29 05:39:59 EDT
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.
Comment 63 Fedora End Of Life 2015-06-29 08:46:30 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.