Just to clarify here, with the Next PPA, its gnome-shell 3.10 with gnome-settings-daemon is 3.8. With Staging PPA g-s-d is 3.10 so using mutter DisplayConfig.

Obviously the real problem here is the monitor size is not detected correctly by X, however apparently this is quite a common problem with HDMI monitors. Perhaps mutter display config needs to be a little smarter in this case?

Created attachment 260069 [details]
output from X -verbose 6 > /home/ph/xlog.txt 2>&1

As you can see from this output which gives a very detailed view of EDID, on line  219 the Maximum Image Size is 1210 mm x 680 mm- that is correct and equates to 55" (which is the size of my monitor).

However from line 248 under detailed timings the Image size is listed as 160 mm x 90 mm (or 7").

It also states on line 217: Prefer first detailed timing : Yes

So what is happening is the Gnome Settings Daemon from the next ppa is using xrandr direct (as I've been told), and setting the correct display size of 55" from the Maximum Image Size and DPI is working as expected.

But the new way g-s-d is getting the display size is from the reported Image Size as obtained from X which is set by the detailed timings. In this case the EDID displays the Image size as 160 mm x 90 mm (7") and hence the display is being set as 7"

Now this seems to be the case for 3 other people with 3 different brands of large screen monitors, which seems to indicate that Image Size from EDID for the detailed timings are set to a smaller than actual value for whatever reason.

As you can also see starting from line 1040, I attempted to work around this with a custom mode in xorg.conf based on the 1st detailed mode and it says:

Mode is rejected: Only EDID-provided modes are allowed on
SAMSUNG (DFP-1) (continuous frequency modes not allowed).

So some solutions as I see them:

1. Create a custom EDID which is a pain in the ass

2. Have Gnome Settings Daemon force set the display size from the Maximum Image Size with xrandr, whilst taking DPI, hsync, vsync etc from the values X obtains from EDID.

3. Have X do that instead of g-s-d. 

4. Temporarily patch g-s-d to force set it for now and ensure wayland supports this in the future.

Option 1 is not an option as the edid block doesn't contain the required information:

This is an ascii of the extracted EDID:

Section "Monitor"
	# Block type: 2:0 3:fd
	# Block type: 2:0 3:fc
	Identifier "SAMSUNG"
	VendorName "SAM"
	ModelName "SAMSUNG"
	# Block type: 2:0 3:fd
	HorizSync 26-81
	VertRefresh 24-75
	# Max dot clock (video bandwidth) 150 MHz
	# Block type: 2:0 3:fc
	# DPMS capabilities: Active off:no  Suspend:no  Standby:no

	Mode 	"1920x1080"	# vfreq 60.000Hz, hfreq 67.500kHz
		DotClock	148.500000
		HTimings	1920 2008 2052 2200
		VTimings	1080 1084 1089 1125
		Flags	"+HSync" "+VSync"
	EndMode
	Mode 	"1920x1080"	# vfreq 50.000Hz, hfreq 56.250kHz
		DotClock	148.500000
		HTimings	1920 1968 2012 2640
		VTimings	1080 1084 1089 1125
		Flags	"+HSync" "+VSync"
	EndMode
	# Block type: 2:0 3:fd
	# Block type: 2:0 3:fc
EndSection

So the max image size is coming from an extension block and I don't know how to edit that to create a custom one and have xorg.conf point to it.

The edid code actually lives in gnome-desktop. Re-assigning

I actually think we should just avoid doing hidpi for any screens that have resolution less than 2560x1440.  Since we're pixel doubling the lowest effective resolution should be usable.  1280x720 is about as low as we should ever inflict on anyone.

That would mean avoiding looking at the iffy physical dimensions in most cases and cut out a lot of false positives.

Also see the discussion between adamw and ebassi here:

https://bugzilla.redhat.com/show_bug.cgi?id=1025391

I'll close this as a dupe of bug 709859, as this is pretty much the same problem, just more heuristics.

*** This bug has been marked as a duplicate of bug 709859 ***