I'm going to repost the comments in that code which could get overlooked but seem relevant. At a glance: Hard coded dpi?


/* As we cannot rely on the X server giving us good DPI information, and
 * that we don't want multi-monitor screens to have different DPIs (thus
 * different text sizes), we'll hard-code the value of the DPI
 *
 * See also:
 * https://bugzilla.novell.com/show_bug.cgi?id=217790•
 * https://bugzilla.gnome.org/show_bug.cgi?id=643704
 *
 * http://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html
 * Why EDID is not trustworthy for DPI
 * Adam Jackson ajax at redhat.com
 * Tue Oct 4 17:54:57 UTC 2011
 * 
 *     Previous message: GNOME 3 - font point sizes now scaled?
 *     Next message: Why EDID is not trustworthy for DPI
 *     Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
 * 
 * On Tue, 2011-10-04 at 11:46 -0400, Kaleb S. KEITHLEY wrote:
 * 
 * > Grovelling around in the F15 xorg-server sources and reviewing the Xorg 
 * > log file on my F15 box, I see, with _modern hardware_ at least, that we 
 * > do have the monitor geometry available from DDC or EDIC, and obviously 
 * > it is trivial to compute the actual, correct DPI for each screen.
 * 
 * I am clearly going to have to explain this one more time, forever.
 * Let's see if I can't write it authoritatively once and simply answer
 * with a URL from here out.  (As always, use of the second person "you"
 * herein is plural, not singular.)
 * 
 * EDID does not reliably give you the size of the display.
 * 
 * Base EDID has at least two different places where you can give a
 * physical size (before considering extensions that aren't widely deployed
 * so whatever).  The first is a global property, measured in centimeters,
 * of the physical size of the glass.  The second is attached to your (zero
 * or more) detailed timing specifications, and reflects the size of the
 * mode, in millimeters.
 * 
 * So, how does this screw you?
 * 
 * a) Glass size is too coarse.  On a large display that cm roundoff isn't
 * a big deal, but on subnotebooks it's a different game.  The 11" MBA is
 * 25.68x14.44 cm, so that gives you a range of 52.54-54.64 dpcm horizontal
 * and 51.20-54.86 dpcm vertical (133.4-138.8 dpi h and 130.0-139.3 dpi v).
 * Which is optimistic, because that's doing the math forward from knowing
 * the actual size, and you as the EDID parser can't know which way the
 * manufacturer rounded.
 * 
 * b) Glass size need not be non-zero.  This is in fact the usual case for
 * projectors, which don't have a fixed display size since it's a function
 * of how far away the wall is from the lens.
 * 
 * c) Glass size could be partially non-zero.  Yes, really.  EDID 1.4
 * defines a method of using these two bytes to encode aspect ratio, where
 * if vertical size is 0 then the aspect ratio is computed as (horizontal
 * value + 99) / 100 in portrait mode (and the obvious reverse thing if
 * horizontal is zero).  Admittedly, unlike every other item in this list,
 * I've never seen this in the wild.  But it's legal.
 * 
 * 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 of course that's
 * what TV manufacturers do because that way they don't have to modify the
 * EDID info when physical construction changes, and that's cheaper.
 * 
 * e) You could use mode size to get size in millimeters, but you might not
 * have any detailed timings.
 * 
 * f) You could use mode size, but mode size is explicitly _not_ glass
 * size.  It's the size that the display chooses to present that mode.
 * Sometimes those are the same, and sometimes they're not.  You could be
 * scaled or {letter,pillar}boxed, and that's not necessarily something you
 * can control from the host side.
 * 
 * g) You could use mode size, but it could be an encoded aspect ratio, as
 * in case d above, because CEA says that's okay.
 * 
 * h) You could use mode size, but it could be the aspect ratio from case d
 * multiplied by 10 in each direction (because, of course, you gave size in
 * centimeters and so your authoring tool just multiplied it up).
 * 
 * i) Any or all of the above could be complete and utter garbage, because
 * - and I really, really need you to understand this - there is no
 * requirements program for any commercial OS or industry standard that
 * requires honesty here, as far as I'm aware.  There is every incentive
 * for there to _never_ be one, because it would make the manufacturing
 * process more expensive.
 * 
 * So from this point the suggestion is usually "well come up with some
 * heuristic to make a good guess assuming there's some correlation between
 * the various numbers you're given".  I have in fact written heuristics
 * for this, and they're in your kernel and your X server, and they still
 * encounter a huge number of cases where we simply _cannot_ know from EDID
 * anything like a physical size, because - to pick only one example - the
 * consumer electronics industry are cheap bastards, because you the
 * consumer demanded that they be cheap.
 * 
 * And then your only recourse is to an external database, and now you're
 * up the creek again because the identifying information here is a
 * vendor/model/serial tuple, and the vendor can and does change physical
 * construction without changing model number.  Now you get to play the
 * guessing game of how big the serial number range is for each subvariant,
 * assuming they bothered to encode a serial number - and they didn't.  Or,
 * if they bothered to encode week/year of manufacturer correctly - and
 * they didn't - which weeks meant which models.  And then you still have
 * to go out and buy one of every TV at Fry's, and that covers you for one
 * market, for three months.
 * 
 * If someone wants to write something better, please, by all means.  If
 * it's kernel code, send it to dri-devel at lists.freedesktop.org and cc me
 * and I will happily review it.  Likewise xorg-devel@ for X server
 * changes.
 * 
 * I gently suggest that doing so is a waste of time.
 * 
 * But if there's one thing free software has taught me, it's that you can
 * not tell people something is a bad idea and have any expectation they
 * will believe you.
 * 
 * > Obviously in a multi-screen set-up using Xinerama this has the potential 
 * > to be a Hard Problem if the monitors differ greatly in their DPI.
 * > 
 * > If the major resistance is over what to do with older hardware that 
 * > doesn't have this data available, then yes, punt; use a hard-coded 
 * > default. Likewise, if the two monitors really differ greatly, then punt.
 * 
 * I'm going to limit myself to observing that "greatly" is a matter of
 * opinion, and that in order to be really useful you'd need some way of
 * communicating "I punted" to the desktop.
 * 
 * Beyond that, sure, pick a heuristic, accept that it's going to be
 * insufficient for someone, and then sit back and wait to get
 * second-guessed on it over and over.
 * 
 * > And it wouldn't be so hard to to add something like -dpi:0, -dpi:1, 
 * > -dpi:2 command line options to specify per-screen dpi. I kinda thought I 
 * > did that a long, long time ago, but maybe I only thought about doing it 
 * > and never actually got around to it.
 * 
 * The RANDR extension as of version 1.2 does allow you to override
 * physical size on a per-output basis at runtime.  We even try pretty hard
 * to set them as honestly as we can up front.  The 96dpi thing people
 * complain about is from the per-screen info, which is simply a default
 * because of all the tl;dr above; because you have N outputs per screen
 * which means a single number is in general useless; and because there is
 * no way to refresh the per-screen info at runtime, as it's only ever sent
 * in the initial connection handshake.
 * 
 * - ajax
 * 
 */

out of interest what is the dpi setting you have in your /etc/X11 configuration files?

The problem simply is that the XSettings code for window scaling doesn't follow resolution changes.

Ray, you'll have to pick this problem up as I have no hardware to test it.

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

We should:
- listen to XRandR events, note that it's more than just window_scale that changes when the XRandR setup changes. This should be as easy as doing the same calls as xft_callback() when we receive a monitors-changed signal.
- Don't scale when the display is not at full "native" resolution
- Ignore size on HDMI outputs. This is blunt, but it's better than hard-coding resolutions (eg. the Surface Pro has a 10.6" 1920x1080, which equates to 208 dpi[1], I'd expect hi-dpi to get toggled on).

[1]: http://members.ping.de/~sven/dpi.html

Created attachment 260295 [details] [review]
xsettings: Use primary monitor for scaling factor

Not screen 0.

Created attachment 260296 [details] [review]
xsettings: Use correct flags for test application

The other test app might not have the same requirements as the
full plugin test app.

Created attachment 260297 [details] [review]
xsettings: Check native resolution for scaling factor

Check whether the panel is running at its native resolution before
applying the scaling factor. We don't want hi-dpi screens running
below native resolution to have a high scaling factor.

Created attachment 260298 [details] [review]
xsettings: Disable scaling factor on HDMI outputs

If the output is HDMI, it's likely that the output is a TV, so
don't increase the scaling factor.

Created attachment 260299 [details] [review]
xsettings: Enable hidpi scaling on 4K monitors

Even if HDMI is used.

Should just be missing listening to XRandR events.

(In reply to comment #6)

> - Ignore size on HDMI outputs. This is blunt, but it's better than hard-coding
> resolutions (eg. the Surface Pro has a 10.6" 1920x1080, which equates to 208
> dpi[1], I'd expect hi-dpi to get toggled on).
Do you really want your surface pro to be effectively 960x540 ? That seems wrong.

(In reply to comment #13)
> (In reply to comment #6)
> 
> > - Ignore size on HDMI outputs. This is blunt, but it's better than hard-coding
> > resolutions (eg. the Surface Pro has a 10.6" 1920x1080, which equates to 208
> > dpi[1], I'd expect hi-dpi to get toggled on).
> Do you really want your surface pro to be effectively 960x540 ? That seems
> wrong.

That's not what doubling the scale factor should do, or does. Content should still be the same size, it's icons and toolkit bits that will get bigger.

Bastien: Well, not quite. If you're showing a photo it'll still show the same amount of pixels as without it, but it *does* makes fonts larger which means you can't fit as much text. However, that can easily be remedied by picking a slightly smaller default font text. (You likely had to instead chose a slightly *larger* default font if scaling wasn't enabled anyway)

(In reply to comment #15)
> Bastien: Well, not quite. If you're showing a photo it'll still show the same
> amount of pixels as without it, but it *does* makes fonts larger which means
> you can't fit as much text. However, that can easily be remedied by picking a
> slightly smaller default font text. (You likely had to instead chose a slightly
> *larger* default font if scaling wasn't enabled anyway)

Fair enough, but I'd wait until we get reports of such devices showing problems before adding more heuristics to the code. It's the way it works now as well, and we didn't get reports about it yet (only external HDMI monitors/TVs and sub-native resolution monitors).

Hey there,

Ummm looks like you guys are sort of saying your happy with the way the code is now?

Because for me it's definitely a regression. I upgraded from 3.10 next ppa in gnome ubuntu where my Samsung 55" tv is detected correctly and everything looks normal for fonts and cursors.

to 3.10 staging ppa, where the fonts and cursors are HUGE. This also seems to affect the edges of windows for resize handles where they appear to be 1 pixel or don't appear at all, and my TV is detected as 7".

There is no manual fix for this either by trying to set modelines, or changing the DPI settings in xorg.conf, as my video card complains that it can ONLY accept EDID settings from the TV.

So what I have done is use gnome tweak tool to scale down to the LOWEST available setting in there (.5) to get the fonts looking normal, but the cursors are still HUGE and the resize handles still don't work in some apps like nautilus.

Also the login screen looks crap as tweak tool is user based.

I am patiently waiting for a fix for this as I detailed in my bug https://bugzilla.gnome.org/show_bug.cgi?id=712529

I know at least 3 others affected by this on 3 different brands of TV\monitors. They may not be complaining or reporting this as an issue because they rolled back to 3.8 or if for example you have 2 monitors you don't get affected by this issue if at least one of them is being detected correctly.

If I'm wrong and your last reply is not implying that your just happy to leave things the way they are then please ignore this, but if you are intending to leave things the way they are then please don't because it sucks ass :)

Or can you let me know how to fork g-s-d and add back the code from the next ppa, where it appears to be using my max image size in EDID to determine the screen size from xrandr, and set things appropriately? Because I'll do that rather than put up with the crap look and feel of gnome-shell as it currently stands.

Cheers

(In reply to comment #17)
> Ummm looks like you guys are sort of saying your happy with the way the code is
> now?

Completely, we just create patches for giggles.

> If I'm wrong and your last reply is not implying that your just happy to leave
> things the way they are then please ignore this

We will.

>, but if you are intending to
> leave things the way they are then please don't because it sucks ass :)

I'm not sure why you think using such language is alright just because you add a smiley after it.

didn't mean to offend - your last reply could be interpreted as just leave it the way it is until we get more complaints from people, at least that's the way I read it.

(In reply to comment #19)
> didn't mean to offend - your last reply could be interpreted as just leave it
> the way it is until we get more complaints from people, at least that's the way
> I read it.

Not if you read the discussion which went from comment 13 to comment 16 (inclusives). Comment 16 also explicitely states that we only care about HDMI outputs and sub-native resolutions.

Yes I see, sorry just protecting my bug which got squished up into this one, which is dealing with more than one issue.

I was kind of hoping for an easy fix and I Misread your response as relating to my bug... as in it won't get changed till more people complain :p So I was complaining :S my bad sorry

Created attachment 262878 [details] [review]
xsettings: Use correct flags for test application

The other test app might not have the same requirements as the
full plugin test app.

Bastien,

Can I use these diffs to patch xsettings and build it, so I can temporarily work around the huge fonts and cursors I have?

oops - sorry I can see it's gnome-settings-daemon I need to patch. Nevermind I'll sort it out once I setup ubuntu gnome with jhbuild

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

lol - i do not understand how or why that makes a difference but it does.

I had already set that to 0.5 with gnome-tweak-tool to get it from HUGE to just about right, but the cursors stayed big.

When I ran gsettings get org.gnome.desktop.interface text-scaling-factor

it was set at 0.50000000000015

When I ran gsettings set org.gnome.desktop.interface text-scaling-factor 1

Which is what it was before when it was HUGE, no immediate change, so I did alt + f2 r, and the fonts and cursors went back to normal?!?

What's up with that?

I'll see how it holds up after a reboot, but I imagine it would be reset and I'd have to run that and restart the shell after each reboot...

Nope it didn't stick on a reboot and it's not behaving the same way now after the reboot, ie setting the scaling-factor back to 0.5 reduces the size, but setting it back to 1 just increases it and the cursors aren't affected by either change.

I have a feeling that with gnome-tweak-tool set at .5 at boot, then running gsettings to set it to 1 might be the trick, but I think i'm just going to reinstall base system, jhbuild and patch and build gnome-settings-daemon instead

(In reply to comment #22)
> Created an attachment (id=262878) [details] [review]
> xsettings: Use correct flags for test application
> 
> The other test app might not have the same requirements as the
> full plugin test app.

Hi there,

Could you pretty please supply a patch for gnome-shell 3.10.2.1-3? Gnome-Settings-Daemon 3.10.2-3

I have tried patching this with your patches here, but they are obviously for a different version.... 

It's really frustrating me :S

Pretty Pretty please :)

(In reply to comment #28)
> (In reply to comment #22)
> > Created an attachment (id=262878) [details] [review] [details] [review]
> > xsettings: Use correct flags for test application
> > 
> > The other test app might not have the same requirements as the
> > full plugin test app.
> 
> Hi there,
> 
> Could you pretty please supply a patch for gnome-shell 3.10.2.1-3?
> Gnome-Settings-Daemon 3.10.2-3

There's nothing to test yet.

(In reply to comment #29)
> (In reply to comment #28)
> > (In reply to comment #22)
> > > Created an attachment (id=262878) [details] [review] [details] [review] [details] [review]
> > > xsettings: Use correct flags for test application
> > > 
> > > The other test app might not have the same requirements as the
> > > full plugin test app.
> > 
> > Hi there,
> > 
> > Could you pretty please supply a patch for gnome-shell 3.10.2.1-3?
> > Gnome-Settings-Daemon 3.10.2-3
> 
> There's nothing to test yet.

Hi, sorry I thought the patch xsettings: Disable scaling factor on HDMI outputs would do that...

Is there a way you could see it in you're heart to write a little patch for gnome-settings-daemon 3.10.2 for the HDMI tv's where they're being set to 7"?

It's really doing my head in with the huge cursors, fonts all blurry, huge title-bars, apps that don't resize fonts according to text-scaling-factor etc

Here's an example of the huge bars, blurry font etc:

http://farm6.staticflickr.com/5504/11215516045_7b6a205c6d_o.png

This shows even if i click view -> Larger Text (approx 10 times), the font still looks blurry:

http://farm8.staticflickr.com/7305/11215515345_ffe8bd416b_o.png (doesn't show clearly in the screenshot but it looks blurry onscreen)

Why I have to increase the text for this app is odd, considering i need to decrease it for everything else...

(In reply to comment #30)

> It's really doing my head in with the huge cursors, fonts all blurry, huge
> title-bars, apps that don't resize fonts according to text-scaling-factor etc

Objectively, it is hard to tell what the problem is without specifics. What apps have fonts that are too big? What apps have them too small?

So you know the range for gsettings set org.gnome.desktop.interface text-scaling-factor is between 0.5 and 3 you can test this yourself by running 

$ gsettings range org.gnome.desktop.interface text-scaling-factor

Your cursor size can be adjusted with a gsetting as well

There seem to be a number of font settings for various applications in gsettings  org.gnome.desktop.interface schema. Check each of them.

gsettings list-recursively org.gnome.desktop.interface

You might want to download dconf-editor if you haven't already. This should allow you to store your settings too I think.

Find out more with 

man gsettings 
or 
gsettings --help

(In reply to comment #32)
> (In reply to comment #30)
> 
> > It's really doing my head in with the huge cursors, fonts all blurry, huge
> > title-bars, apps that don't resize fonts according to text-scaling-factor etc
> 
> Objectively, it is hard to tell what the problem is without specifics. What
> apps have fonts that are too big? What apps have them too small?
> 
> So you know the range for gsettings set org.gnome.desktop.interface
> text-scaling-factor is between 0.5 and 3 you can test this yourself by running 
> 
> $ gsettings range org.gnome.desktop.interface text-scaling-factor
> 
> Your cursor size can be adjusted with a gsetting as well
> 
> There seem to be a number of font settings for various applications in
> gsettings  org.gnome.desktop.interface schema. Check each of them.
> 
> gsettings list-recursively org.gnome.desktop.interface
> 
> You might want to download dconf-editor if you haven't already. This should
> allow you to store your settings too I think.
> 
> Find out more with 
> 
> man gsettings 
> or 
> gsettings --help

Hi I should have updated this but forgot to.

Halfline (IRC) gave me some tips, so the following solution now has me almost to a normal desktop again:

1. Gnome Tweak Tool - set font scaling to 0.5 or run gsettings set org.gnome.desktop.interface text-scaling-factor 0.5 (Originally 1)

2. in /etc/environment add "GDK_SCALE=1" without quotes

3. run: gsettings set org.gnome.desktop.interface cursor-size 12 (Originally 24)

As I recall it seemed to be affecting GTK windows for example nautilus, gnome control panel, gnome tweak tool etc. Those windows would take up the entire desktop like I was running a 640x480 resolution.

All cursors were double the size in text boxes, but for non GTK windows the resize handles would be normal size, but in GTK windows the resize handles would be double the size.

The issue has to do with the change in gnome-settings-daemon. Before it was using xrandr directly to get the Display size. Now it's using mutter I believe to get the settings as report by X. So X is just getting the display size as set by EDID and for HDMI attached TV's as per your post in comment 1, the TV's are reporting as 16cm x 9cm and therefore mutter is setting the display size to 7" and everything is getting screwed up because of that.

My TV also reports 1210 mm x 680 mm but it is in the extended EDID information, under Maximum Image Size. I assume that is what xrandr was using to set the Disply size to 55" correctly, in the previous version of gnome-settings-daemon in gnome-shell 3.10.1.

Just to note also Halfline is working on a patch for this issue and hopefully he will have something soonish.

I'd dare to say that you will be getting a lot more complaints when Fedora 20 is released in the next few days, which has gnome-shell 3.10.2 as it's default desktop.

By "almost to a normal desktop again" I mean that certain things are still odd that I believe are still related to this issue.

Like for example if say I have a non maximised window and I maximise it, then click and drag the toolbar so as to move the window (and restore it's previous size in the process) the window jumps to an image of that window with big blurry fonts and icons) and when I let go of the mouse it restores to it's previous size and everything looks fine again.

Also some windows have super small font in the title bar (i'll update again with the apps that are affected)

lol on a side note the GDK_SCALE=1 has also fixed my cairo-dock bug that I've wasted 3 or 4 days trying to resolve.

The desktop was being scaled off-screen - and cairo-dock was loading normally with no errors, but only the workspace desktop plugin was showing on the desktop. No cairo-dock bar....

I only noticed the difference that you can see in the comparison of these 2 images:

http://farm4.staticflickr.com/3814/11246902274_697cb56ae6_o.jpg

As you can see on the right the dock is appearing as it should (with GDK_SCALE=1) and the one on the left (Without GDK_SCALE=1), it's been scaled off screen somewhere.

Fedora 20 new installer here, and you are right. You'll be getting more complaints from Fedora 20 users. It is well known (and even "quirked" in the X server) that Samsung TVs do not bother to report the real size, but merely always say 160mmx90mm to get the aspect ratio correct. Everything worked perfectly because the video drivers got the quirked size of 0x0 and just defaulted to 96DPI. Now Gnome is trying to be "helpful" and digging up the low level info X already decided it should ignore. GAH! Make it stop!

I've seen several hints over the years that people were considering kernel options to let me override the EDID info before anyone else sees it. I'd love to do that, as it would be a permanent fix and prevent the next "helpful" thing from screwing it up again. I don't suppose that has actually happened has it?

Review of attachment 260297 [details] [review]:

This is not really a proper review or anything. I just thought I would draw attention to the fact you wrote a lot of different patches which nobody seems to have given them a review of yet since I have been keen to find out people's thoughts in particular, I want to see what people think of this one.

Aside from that I am also curious about whether the problem is something that can be more easily resolved via wayland. Do you or anyone else here have any thoughts on that?

I managed to hack my EDID and created a custom EDID (which was easy enough but definitely not straight forward and not something the general public would be able to do without some serious hand holding).

What I did was set the physical size from 160mm x 90mm for the preferred resolution sections to what it actually is 1210 x 680.

I had to use 3 different EDID tools to accomplish this, and it involves having to break it at first to get the correct hex for setting it at 1210 x 680, having first identified what hex code to look for and then copying the changed hex through another utility into the correct place in the original EDID.

I have my resolution working as normal, audio over HDMI (NVidia card) is working but not as expected. ie it only detects one device now in the control panel under sounds, namely: Digital Stereo (HDMI) output, where as with the default EDID it detects two, the above and also surround 5.1. But I get HD audio passthrough working as expected.

I'm not 100% sure whether or not this is impacting other apps because I haven't tested that side as yet. I suspect the surround 5.1 missing might be a new 'feature' in gnome-shell or a separate bug.

I'm not so sure I like the idea Tom Horsley suggests as the way to go towards a permanent fix, to avoid (once this gets fixed) it getting broken again in the future, as I don't trust the custom edid method, it is very hit and miss and a bit hocus pocussy.


Tom if you'd like some assistance in creating your own custom edid then let me know

The other hacks in here got it mostly working for me, but if I ever do want to try for custom EDID, I figure the thing to do is delve into the kernel modesetting and X server code that reads EDID - the only parts I need to get right are the parts linux actually tries to read :-).

Well actually it's a bit easier than that. You just get your current edid through various available utilities (you can do it through NVidia as well if you have an NVidia card), then edit that edid file, and point to the custom edid in xorg.conf, along with a couple of other tweaks in xorg.conf

I tried modesetting but my samsung doesn't allow it, so only option was for custom edid.

This gives you an idea but it's not what we are trying to achieve, but it gives you links to a couple of nice tools I used:

http://www.overclock.net/t/1368603/howto-patching-up-your-edid

You need another tool (I'll have to track it down), along with the 3 tools on the above page.

You will notice when highlighting the sizes 16 & 9 in detailed view in Edid Manager, it will highlight hex blocks in 2 different locations on either side of each other. So that's where the tricky part comes in.

You need another tool as I said, which allows you to edit the size and save that in another custom edid. Then use edid manager or edid editor to view the custom edid (it will be about half the size as it breaks the extended part of the edid), but it will give you the correct hex codes to put in place of the 3 blocks you need to edit.

You then change them in the original edid file in edid editor (not manager), and save it and then open it in edid manager to confirm the correct horizontal and vertical sizes now show up.

That will fix this problem and your audio etc will still work as well.

Also it does mention on the above page about ignoring the checksum in xorg.conf.

You can boot without that option, and it will tell you the correct checksum now you edited it, then re edit it and change the checksum to the correct value. Or just ignore it in xorg.conf - either way works

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

Review of attachment 260295 [details] [review]:

After reading through the comments, this seems mostly orthogonal to the other issues, and I can also manually trigger a GSD refresh from settings if I need to. I'd it possible to get this committed?

Hum, shame this got more complicated than discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1025391 :/

One drive-by note: the comment on https://bug709859.bugzilla-attachments.gnome.org/attachment.cgi?id=260298 claims "If the output is HDMI, it's likely that the output is a TV", but I'm not sure that's particularly true.

Every one of Dell's current 'U' series monitors except the obsolescent U2412 has an HDMI input - the U2413, U2414H, U2713HM, U2713H, U3014, UP2414Q, UP3214Q (those last two are UHD monitors, and so precisely the kind that we want hidpi support to work on). So does the P2815Q (another UHD monitor). So do most of the S series monitors, one of the E series, and about a third of the P series. Most of the top ten monitors at http://products.ncix.com/category/lcd-monitors-9b-1003.htm (where I buy most of my stuff) lists HDMI input. Every one of the top ten video cards at http://products.ncix.com/category/video-cards-91-108.htm lists HDMI output.

There is a use case for preferring HDMI to other connections, too - it can carry audio.

So, I'm not sure it's a safe assumption to just throw out HDMI connections for hidpi purposes, though it sure would be an easy one :/

How about combining the 'don't do hidpi for HDMI' and 'don't do hidpi for lower resolutions' ideas to 'don't do hidpi for HDMI outputs under UHD/4K resolution'?

I filed https://bugzilla.gnome.org/show_bug.cgi?id=723624 , too, suggesting a setting for this be added to gnome-tweak-tool. It seems like a reasonable candidate.

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

Review of attachment 260295 [details] [review]:

Looks good to me and tests to work (modulo having to adjust some other setting to get the code to retrigger)

Review of attachment 260297 [details] [review]:

First, let me say, I have no understanding of why people run panels at non-native resolution to start with :-)

But that being said, I don't know if this is a good idea - especially considering that our choice of modes presented is a bit arbitrary, I could easily imagine that if a laptop has a display, a 13" laptop with a 3200x1800 hi-dpi display also has a 2560x1440 option as a listed mode - and that's also a hi-dpi mode. If the user picks that size, it's a little unexpected if everything on the screen suddenly gets much *smaller*.

What's the reasoning for not just looking at the DPI? The only thing I can think of is that in hi-dpi mode, some amount of content is pixel-scaled upwards (images on web pages, say) and a double scale is going to be extremely fuzzy. But I think the main thing we want to enable when the user picks a non-native mode is them having maximum ease at using the controls to switch back when they realize that it looks horrible :-) Which would argue for not risking very small controls.

The code here looks reasonable except that (as I understand it) we're trying to avoid gnome_rr_screen_new() now in GSD because that it doesn't work until Mutter is started, which happens after *gsd* - so we need to use gnome_rr_screen_new_async() instead. We can land this patch set and fix up on top.

It also seems a bit strange to mix GnomeRRScreen with GDK information but in the async world, it's probably right - the GDK information is an approximation that is right in the case where we don't modeset on login or change the primary screen. If we just used a scale factor of 1 until GnomeRRScreen appeared, we'd have a xsettings switch and visual glitch on startup on all hi-dpi systems, rather than just on a subset.

Review of attachment 260298 [details] [review]:

Hmmm, certainly small dense HDMI displays exist, e.g:

 http://www.adafruit.com/products/1033

(~200dpi) But a quick search doesn't reveal anything having enough vertical resolution to usefully run GNOME with a scale factor of two - 1920x1080 is about as small as I can imagine for that. I'm sure that the these heuristics are going to take adjustment over time as the set of available devices changes.

::: plugins/xsettings/gsd-xsettings-manager.c
@@ +508,3 @@
+                rr_screen = gnome_rr_screen_new (gdk_screen_get_default (), NULL);
+                if (!rr_screen)
+                        goto out;

This needs adjustment for asynchronous handling - until we get a GnomeRRScreen, we still want to do the check based on information from GTK+

Review of attachment 260299 [details] [review]:

Looks fine - a bit theoretical until HDMI 2.0 monitors/televisions/gpus become available - needed for 4k at 60hz.

Review of attachment 262878 [details] [review]:

You certainly have the best idea of how you want this to work - the difference between the two sets of flags seems quite small - only the presence or absence of XSETTINGS_CFLAGS

I see the description "Use primary monitor for scaling factor" here.

Just to ask an obvious questions: Isn't this entire concept utterly and completely broken unless the scaling factor is a per-monitor setting?

Would you really want to use a dual monitor setup with one 4K monitor and one regular HD monitor and only have the choice of one monitor being readable?

(In reply to comment #52)
> I see the description "Use primary monitor for scaling factor" here.
> 
> Just to ask an obvious questions: Isn't this entire concept utterly and
> completely broken unless the scaling factor is a per-monitor setting?

That's not possible under X.

> Would you really want to use a dual monitor setup with one 4K monitor and one
> regular HD monitor and only have the choice of one monitor being readable?

On wayland we can fix it properly.

> > Just to ask an obvious questions: Isn't this entire concept utterly and
> > completely broken unless the scaling factor is a per-monitor setting?
> 
> That's not possible under X.

Say that's not possible under GTK and I'll believe you. X will let
me draw any bits I want to draw, its just a question of how much
work you want to trigger when dragging an app from one display to another.

> > Would you really want to use a dual monitor setup with one 4K monitor and one
> > regular HD monitor and only have the choice of one monitor being readable?
> 
> On wayland we can fix it properly.

At least make it possible to completely disable this "feature" at the
user level so it never does anything at all with the scaling factor. Setting an inverse scaling factor is not the same as turning it off since it is a per-user setting and applies even when I'm running remote on a completely different monitor, etc. I need it to just stop doing this.

Created attachment 271796 [details] [review]
xsettings: Use gnome_rr_screen_new_async()

Since gnome-settings-daemon starts before Mutter, we need to use
gnome_rr_screen_new_async() to wait for Mutter to start and provide
the screen information over D-Bus.

Created attachment 271797 [details] [review]
xsettings: Don't mix GnomeRR and GDK information

If we don't mix information from GnomeRR and GDK, then the "changed"
signal on GnomeRRScreen is all we need to properly know when the
resolution of the system is changed - mixing them presents problems
because GDK may not yet have updated it's information from X when the
"changed" is triggered by a D-Bus signal.

We still use GDK information before we have a GnomeRRScreen to minimize
the chance of switching the window scale during startup.

Created attachment 271798 [details] [review]
xsettings: Never turn on hi-dpi support for small resolutions

If the screen is less than 1200 pixels high, don't turn on hi-dpi
support - GNOME isn't going to work with that little vertical
real estate, and it's better just to be small.

Created attachment 271799 [details] [review]
xsettings: remove check for native resolution when determining hi-dpi

A non-native resolution, can still be hi-dpi - e.g., on my laptop,
gnome-settings-daemon lists a resolution of 1920x1440 on my 2560x1440
display. The other checks we have in place should be sufficient to
disable hi-dpi support if the user picks a small resolution.

The patch I attached here are on top of the previous patches on the bug for clarity - I think they can just land like that even thought they modify/revert some bits of the previous patches.

These patches get the g-s-d code working pretty well from my perspective - it reacts correctly to dynamic changes, follows the primary monitor, and has reasonable sanity checks to deal with cases where we get bad monitor information.

(In reply to comment #54)
> > > Just to ask an obvious questions: Isn't this entire concept utterly and
> > > completely broken unless the scaling factor is a per-monitor setting?
> > 
> > That's not possible under X.
> 
> Say that's not possible under GTK and I'll believe you. X will let
> me draw any bits I want to draw, its just a question of how much
> work you want to trigger when dragging an app from one display to another.

The thing is, apps are not necessarily just on one monitor or another - they often cross monitors. Handling this situation well is not possible in any reasonable interpretation of "X" - you'd have to have a completely custom protocol between the applications and the compositor, and at that point you've invented a new window system.

The reason for this is that an X compositor has no control over input events - it can only control output. So it can't rescale a window when drawing, because if it scaled a window the users clicks would no longer correspond to the window controls.

With Wayland, we can tell an application the scale factor for the monitor it is "mostly" on, and scale it up or down on another monitor.

Yes, it might be possible to make the scale factor per-window in X, so if a window was just on one monitor or the other, then things would be OK, and only would be weird if it crossed. But it's a lot of work, requires redoing the work that has already been done, and just isn't worth it compared to putting the work into the move to Wayland.

> > > Would you really want to use a dual monitor setup with one 4K monitor and one
> > > regular HD monitor and only have the choice of one monitor being readable?
> > 
> > On wayland we can fix it properly.
> 
> At least make it possible to completely disable this "feature" at the
> user level so it never does anything at all with the scaling factor. Setting an
> inverse scaling factor is not the same as turning it off since it is a per-user
> setting and applies even when I'm running remote on a completely different
> monitor, etc. I need it to just stop doing this.

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

See bug 723624 for adding that to gnome-tweak-tool (But you commented there, so you know that bug. We're not adding it to System Settings, because we think we that we can get it right most of the time automatically, and we really want to keep the Displays focused on what people normally need to do.)

(In reply to comment #60)
>  gsettings set org.gnome.desktop.interface scale-factor 1

That doesn't work. That is a single per-user setting. If I run a GTK app on one machine over a forwarded X connection, I'll get the local user scale-factor applied to an app that is actually running on a completely different remote display. I need to be able to tell the toolkit it shouldn't turn on any hi-dpi code. All those patches above mention disabling hi-dpi for various reasons. Why not have "gsettings set org.gnome.desktop.interface hi-dpi off" among the many reasons?

(In reply to comment #61)
> (In reply to comment #60)
> >  gsettings set org.gnome.desktop.interface scale-factor 1
> 
> That doesn't work. That is a single per-user setting. If I run a GTK app on one
> machine over a forwarded X connection, I'll get the local user scale-factor
> applied to an app that is actually running on a completely different remote
> display. I need to be able to tell the toolkit it shouldn't turn on any hi-dpi
> code. All those patches above mention disabling hi-dpi for various reasons. Why
> not have "gsettings set org.gnome.desktop.interface hi-dpi off" among the many
> reasons?

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

Seems to be exactly the "hi-dpi off" that you are asking for. It puts things back to the way things were before any hi-dpi code was added to GTK+ or GNOME.

You can also set GDK_SCALE=1 in your environment if you want to make a GTK+ application act like non-hidpi-aware application - it will pick up large fonts if the current session has large fonts, but the rest of the application's UI will remain unscaled.

Unfortunately, there is no way (without editing user code) to make different applications have different font sizes. Font size is a per-session attribute.

I'd appreciate it if we could focus in this bug report on the subject of this bug report, which is improving the automatic selection of the window scale based on properties of the display device.

(In reply to comment #62)

>  gsettings set org.gnome.desktop.interface scaling-factor 1
> 
> Seems to be exactly the "hi-dpi off" that you are asking for. It puts things
> back to the way things were before any hi-dpi code was added to GTK+ or GNOME.

That certainly wasn't the way it acted when it incorrectly turned on hi-dpi on my Samsung TV. I had to set scaling-factor to 0.5 to fit things on the screen. Which then did indeed make things tiny when I remotely accessed the system.

(In reply to comment #63)
> (In reply to comment #62)
> 
> >  gsettings set org.gnome.desktop.interface scaling-factor 1
> > 
> > Seems to be exactly the "hi-dpi off" that you are asking for. It puts things
> > back to the way things were before any hi-dpi code was added to GTK+ or GNOME.
> 
> That certainly wasn't the way it acted when it incorrectly turned on hi-dpi on
> my Samsung TV. I had to set scaling-factor to 0.5 to fit things on the screen.
> Which then did indeed make things tiny when I remotely accessed the system.

I think you are confusing scaling-factor and text-scaling-factor

Review of attachment 271796 [details] [review]:

Looks good.

Review of attachment 271797 [details] [review]:

I don't really like this, but I guess it's needed on startup.  I'm a little bit afraid that this would get re-triggered if there was a saved xrandr configuration. So you'd get something applied without using XRandR/mutter, mutter becomes available, xrandr plugin gets its GnomeRRScreen, resolution changes, and we re-trigger here.

Mutter doesn't show text during its startup sequence, so I would expect it to show up on the bus before it actually displays text, so this might not be necessary.

Review of attachment 271798 [details] [review]:

Good idea, until we run on phone-size screens :)

Review of attachment 271799 [details] [review]:

Right.

(In reply to comment #66)
> Review of attachment 271797 [details] [review]:
> 
> I don't really like this, but I guess it's needed on startup.  I'm a little bit
> afraid that this would get re-triggered if there was a saved xrandr
> configuration. So you'd get something applied without using XRandR/mutter,
> mutter becomes available, xrandr plugin gets its GnomeRRScreen, resolution
> changes, and we re-trigger here.

This definitely *can* happen - it will happen, for example, in Ray's original case where he as a hi-dpi panel configured at a lower resolution.

 - g-s-d starts up, determines from Xrandr information via GDK that the system is hi-dpi
 - Mutter starts up, mode sets to the saved mode, g-s-d sees that and drops the scaling factor back to 1.
 
But the alternative is that we do the same thing *without* the saved mode:

 - g-s-d starts up, can't get a GnomeRRScreen, reports a default scale of 1
 - Mutter starts up, g-s-d sees the GnomeRRScreen, changes the scale to 2

To me, it's more important to prefer keeping things smooth when we *don't* change the mode, don't cause a resync, and are using the native panel resolution.

> Mutter doesn't show text during its startup sequence, so I would expect it to
> show up on the bus before it actually displays text, so this might not be
> necessary.

It's going to be racy whether it reads the PropertyNotify events for the XSETTINGS change before it draws the first frame. Hard for me to guess whether we're usually going to win or lose.

I discussed with Giovanni having g-s-d set a root window property after it gets the GnomeRRScreen and sets final settings, and then to have Mutter wait for that before starting the user interface. This would make sure we got things exactly right, but seemed low priority for 3.12, especially since we we were also discussing possibly changing the startup sequence for X for 3.14 so Mutter starts before g-s-d - Wayland has to work that way, so it would reduce code path differences.

Attachment 260295 [details] pushed as 5337837 - xsettings: Use primary monitor for scaling factor
Attachment 260297 [details] pushed as 4125970 - xsettings: Check native resolution for scaling factor
Attachment 260298 [details] pushed as d691c9c - xsettings: Disable scaling factor on HDMI outputs
Attachment 260299 [details] pushed as 5efbd21 - xsettings: Enable hidpi scaling on 4K monitors
Attachment 262878 [details] pushed as 1b22778 - xsettings: Use correct flags for test application
Attachment 271796 [details] pushed as 478b478 - xsettings: Use gnome_rr_screen_new_async()
Attachment 271797 [details] pushed as a7fa483 - xsettings: Don't mix GnomeRR and GDK information
Attachment 271798 [details] pushed as 6279aa3 - xsettings: Never turn on hi-dpi support for small resolutions
Attachment 271799 [details] pushed as 2d8beaf - xsettings: remove check for native resolution when determining hi-dpi

Has a fix been pushed for this yet?

Because I'm still having the same problems with scaling etc and my monitor being detected as 7"

Yawn :)

You...could look up *one* comment.

Will this apply to gnome-shell 3.10.2?

One way to solve the problem is:
$ gsettings set org.gnome.desktop.interface scaling-factor 1

Hi Olivier - that doesn't fix everything, sometimes it works as 1 but usually I have to set mine to .5

But it doesn't fix the icons, and a few other things I can't remember off the top of my head.

The work around I used is to use a custom EDID, and all I changed was the desktop size for the preferred resolution and it works like a charm

Please note it's not text-scaling-factor but just scaling-factor

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

I have the same problem here but I can't find a way to fix it. Yes, running "gsettings set org.gnome.desktop.interface scaling-factor 1" seems to solve the problem except that gnome continue to say that my monitor is 7''; furthermore even gdm3 continue to show all huge... in my opinion this is a workaround not a fix of this bug.

Can you please remove "RESOLVED FIXED" from the status of this bug so we can hoping that will be solved in a future?

Have a great day

Piviul

piviul: well, this is a complex bug, and you didn't provide any details on your case. It would be best to open a new bug, with details about your hardware - kernel logs, xrandr output, that kind of thing. Thanks.