Ignores physical display size and calculates based on 96DPI

Bug #589485 reported by Chris Halse Rogers
354
This bug affects 72 people
Affects Status Importance Assigned to Milestone
X.Org X server
Unknown
High
xorg-server (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

The X server, starting with 1.7, ignores the physical size reported by the EDID or in xorg.conf and calculates it based on screen resolution and a DPI of 96.

This is rather annoying for users of high DPI screens.

GNOME and KDE (used?) to set 96 DPI by default in their settings. We should check whether they still do, and if so let them handle this; I don't think X should be handling this.

Revision history for this message
In , Arkadiusz Miśkiewicz (arekm) wrote :

Created an attachment (id=29210)
X log from 1.6.3 xserver (working setup)

Revision history for this message
In , Arkadiusz Miśkiewicz (arekm) wrote :

Created an attachment (id=29211)
X log from 1.7.0 rc0 (not working properly setup)

Revision history for this message
In , Arkadiusz Miśkiewicz (arekm) wrote :

Created an attachment (id=29212)
xorg.conf used

Revision history for this message
In , Airlied-freedesktop (airlied-freedesktop) wrote :

fff00df94d7ebd18a8e24537ec96073717375a3f

can you try reverting that from 1.7 and seeing if it helps?

Revision history for this message
In , Arkadiusz Miśkiewicz (arekm) wrote :

Reverting that patch (+ small build fix) makes my setup working again:

$ xdpyinfo|grep dimens
  dimensions: 1440x900 pixels (303x190 millimeters)

Now am I supposed to configure this manually via xorg.conf as commit log says?

Revision history for this message
In , Keith Packard (keithp) wrote :

The 'screen size' as reported in the core protocol now respects the DPI value given by the user or config file and ignores the actual monitor DPI of any connected monitor.

The real monitor size is reported through the RandR extension if you really need to know the physical size of the display.

This is intentional and follows the practice seen in many other desktop environments where the logical DPI of the screen is used as an application and font scaling factor.

If you don't like it, you're welcome to configure the X server to taste; we haven't removed any of those knobs. And, you can even use xrandr to change things on the fly.

Revision history for this message
In , Arkadiusz Miśkiewicz (arekm) wrote :

"now respects the DPI value given by the user or config file" - ok but I don't have DPI set in config and don't have DPI set in command line.

I would expect some sane/matching my LVDS value to be used by default in such case.

Also xrandr --dpi 120/LVDS _almost_ works because it's wrong by 1mm. Will try to set size via config then.

Revision history for this message
In , Yves-Alexis Perez (corsac) wrote :

> The 'screen size' as reported in the core protocol now respects the DPI value
> given by the user or config file and ignores the actual monitor DPI of any
> connected monitor.

Hmmh but what's the point? Over the few past years, my xorg.conf has completely disappeared, either because the config is done somewhere else, or because all the settings are correctly autodetected by X. Why having to revert that and specify display size (which the user usually don't really know anyway, while the server does)?

> The real monitor size is reported through the RandR extension if you really
> need to know the physical size of the display.

Yeah so the user needs to use X to get his display size, then edit xorg.conf to tell X the display size. I find that a bit painful and inconsistent

> This is intentional and follows the practice seen in many other desktop
> environments where the logical DPI of the screen is used as an application and
> font scaling factor.

Hmhm, I don't get it. I'm not really comfortable with all that, but if my screen is a high dpi one and my OS supports it, why would I need to do as other crappy os do, and stick with a low resolution, 96 dpi screen?

> If you don't like it, you're welcome to configure the X server to taste; we
> haven't removed any of those knobs. And, you can even use xrandr to change
> things on the fly.

That's good, but I really don't know why it's necessary. Wasn't autodetection working correctly for the majority of users? Couldn't other people use the DisplaySize stuff?

Cheers,

Revision history for this message
In , Julien Cristau (jcristau) wrote :

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

Revision history for this message
In , Nick Bowler (nbowler) wrote :

(In reply to comment #6)
> This is intentional and follows the practice seen in many other desktop
> environments where the logical DPI of the screen is used as an application and
> font scaling factor.

This is definitely a good idea, and it's what many X applications already did. For example, I can tell Firefox to lay out text in a column that is 16cm wide, or I can tell urxvt to use a 9pt font (9pt is 1/8 of an inch). However, these units are only meaningful if the DPI is correct. If X is configured to assume 96dpi, then an application which wants to display something 16cm wide will translate that to 605 pixels. But when it is then output to the attached 129dpi display device, the result is only 12cm wide.

> If you don't like it, you're welcome to configure the X server to taste; we
> haven't removed any of those knobs. And, you can even use xrandr to change
> things on the fly.

I don't mind having to configure the X server to get the desired behaviour. However, after perusing the man pages, I can't find the knob which restores the earlier behaviour of computing the DPI value automatically based on the geometry of the attached monitor. The best solution I've come up with so far (save for patching the server) is adding

xrandr --fbmm `xrandr | sed -n '/ connected / {s/.* \([0-9]\+\)mm x \([0-9]\+\)mm/\1x\2/p;q}'`

to my startup scripts. So yes, the actual size information is available, and yes, the resolution tuned on the fly, but why is pulling a meaningless DPI value out of thin air the default?

Revision history for this message
In , Evgeni Golov (evgeni) wrote :

(In reply to comment #8)
> > The 'screen size' as reported in the core protocol now respects the DPI value
> > given by the user or config file and ignores the actual monitor DPI of any
> > connected monitor.
>
> Hmmh but what's the point? Over the few past years, my xorg.conf has completely
> disappeared, either because the config is done somewhere else, or because all
> the settings are correctly autodetected by X. Why having to revert that and
> specify display size (which the user usually don't really know anyway, while
> the server does)?
>
> > The real monitor size is reported through the RandR extension if you really
> > need to know the physical size of the display.
>
> Yeah so the user needs to use X to get his display size, then edit xorg.conf to
> tell X the display size. I find that a bit painful and inconsistent
>
> > This is intentional and follows the practice seen in many other desktop
> > environments where the logical DPI of the screen is used as an application and
> > font scaling factor.
>
> Hmhm, I don't get it. I'm not really comfortable with all that, but if my
> screen is a high dpi one and my OS supports it, why would I need to do as other
> crappy os do, and stick with a low resolution, 96 dpi screen?
>
> > If you don't like it, you're welcome to configure the X server to taste; we
> > haven't removed any of those knobs. And, you can even use xrandr to change
> > things on the fly.
>
> That's good, but I really don't know why it's necessary. Wasn't autodetection
> working correctly for the majority of users? Couldn't other people use the
> DisplaySize stuff?
>
> Cheers,

+1

My current screen is a 13.3" 1440x900 LCD, resulting in about 127DPI. I was like "WTF has happend???" when I upgraded to 1.7 and saw everything in 96DPI.

Why ignore a valid information we already have? When someone wants to override this, he perfectly can do so. I don't see the point why everyone who wants to have the correct behavior has to configure it by telling xorg "you have the information, use it", it should be "the information you have is wrong, please use X instead" as the old behavior was...

Oh, and btw, which "other desktop environments"? DPI is dots per inch, there can't be any other interpretation than "how many pixels/dots are used for one inch on screen".

Thanks
Evgeni

Revision history for this message
In , Julien Cristau (jcristau) wrote :

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

Revision history for this message
In , Brian Tarricone (kelnos) wrote :

(In reply to comment #6)
> The 'screen size' as reported in the core protocol now respects the DPI value
> given by the user or config file and ignores the actual monitor DPI of any
> connected monitor.

I've read the rest of the comments here and I'm still not sure I understand. What DPI value given by the user or config file? I haven't specified DPI *anywhere* (my xorg.conf file is empty except for 4 lines to set the video driver to 'nouveau' or 'nvidia'). And yet, xdpyinfo reports 96dpi, when the real resolution is 112dpi.

This sounds incredibly inconsistent and not very useful. You're saying I'm forced to either override Xfce's detected DPI (which will only "unbreak" GTK apps, and nothing else), or add entries to my xorg.conf file to set the display size? That makes no logical sense to me. *Please* tell me I'm misunderstanding something here.

(I suspect I may be: when I use nouveau, I get an incorrect DPI from xdpyinfo, even if the logging in Xorg.0.log prints out the correct display size and DPI. When I use nvidia, my DPI is correct everywhere.)

Revision history for this message
In , Andrey Rahmatullin (wrar) wrote :

(In reply to comment #13)
> What DPI value given by the user or config file? I haven't specified DPI
> *anywhere*
Me too.

Revision history for this message
In , Arvidjaar (arvidjaar) wrote :

I do not see any voting possibility here so can only add:

+1/me too.

Revision history for this message
In , Samuel thibault (samuel-thibault) wrote :

Same here, upgrade from 1.6 to 1.7, all my gtk apps started writing
much smaller, it hurts the eyes...

Revision history for this message
In , Nick Bowler (nbowler) wrote :

Created an attachment (id=33081)
Add "DontLie" server flag, to encourage honesty.

In case anyone's interested, here's the patch I've been applying which adds a so-called "knob" to restore the original behaviour. Maybe the flag can be extended to avoid other lies in the future.

xfree86: Add DontLie server flag.

Since commit fff00df94d7ebd18a8e24537ec96073717375a3f, RandR 1.2 drivers
lie about the resolution of the attached screen by default. When the
reported resolution is wrong, fonts and other UI elements that use
physical units are not sized correctly.

This patch adds a new server flag, DontLie, which encourages the server
to be honest by default.

Signed-off-by: Nick Bowler <email address hidden>

Revision history for this message
In , lultimouomo (lultimouomo) wrote :

I'm sorry, but this really looks like an uncalled for change to me.

>This is intentional and follows the practice seen in many other desktop
>environments where the logical DPI of the screen is used as an application and
>font scaling factor.

http://en.wikipedia.org/wiki/Font_size
A point is an unit of measure, 0.353 mm.
If I set a character to be 10 points high, it has to be 3.5mm high on a screen.
I understand this could be not the most natural behaviour on projectors, but the vast majority of people use screens, there's no need to cause them troubles.
(I don't even know if projectors report DPI in their Edid anyway.)
Unless explicitly overridden, X should respect Edid.

Fiddling gratuitously with the DPI makes default configurations almost unusable on high resolution screens (fonts are rendered too small).
It screws up the 1:1 display of documents and images; and I suppose it messes with input devices like tablets and touchscreens.

Even the default of 96dpi doesn't make sense, this resolution is getting less and less common every day.
Users
To further the annoyance, I haven't found a way to ovverride the 96dpi default in xorg.conf:
DisplaySize gets ignored, and so does Option "DPI".
Right now I'm stuck with xrandr --dpi in .xsessionrc - not what I'd call user friendly.
Please reconsider this change in behaviour.
What bug was it supposed to fix?

Regards,

Luca

Revision history for this message
In , Nick Bowler (nbowler) wrote :

(In reply to comment #18)
> http://en.wikipedia.org/wiki/Font_size
> A point is an unit of measure, 0.353 mm.
> If I set a character to be 10 points high, it has to be 3.5mm high on
> a screen.

Just to clarify, setting the font size to 10pt defines the size of an
"em"; the exact meaning of which depends on the selected font (it might
not exactly correspond to the height of a character on screen).

> I understand this could be not the most natural behaviour on
> projectors, but the vast majority of people use screens, there's no
> need to cause them troubles.

The main problem here is that our method of specifying font sizes is not
well suited for devices such as projectors or TVs because it does not
take the viewing distance into account. However, lying about the DPI
doesn't actually improve the situation.

> Fiddling gratuitously with the DPI makes default configurations almost
> unusable on high resolution screens (fonts are rendered too small).

And when it doesn't make fonts unreadable, it makes them ugly.

> Even the default of 96dpi doesn't make sense, this resolution is
> getting less and less common every day.

I have owned exactly one display device in my lifetime with this
resolution: a 17" LCD monitor with 1280x1024 pixels. Most of my CRTs
have higher resolution, and most of my other "external" LCDs have lower.
My laptops have significantly higher resolution than all my other
devices. So from my personal experience, 96 is almost always the wrong
choice. The number seems to have come out of nowhere and makes little
sense as a default.

> Please reconsider this change in behaviour.
> What bug was it supposed to fix?

The commit message says

  Reporting the EDID values in the core means applications get
  inconsistent font sizes in the default configuration.

This makes no sense, since font sizes are consistent only when the DPI
correctly reflects reality! This change *causes* font sizes to be
inconsistent.

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #19)
> 96 is almost always the wrong
> choice. The number seems to have come out of nowhere and makes little
> sense as a default.

It was chosen in order to make display of web pages using Xorg more consistent with the way they get displayed on Windows, which by default assumes 96. http://blogs.msdn.com/fontblog/archive/2005/11/08/490490.aspx explains the origin of 96.

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #19)
> (In reply to comment #18)
> Reporting the EDID values in the core means applications get
> inconsistent font sizes in the default configuration.

> This makes no sense, since font sizes are consistent only when the DPI
> correctly reflects reality! This change *causes* font sizes to be
> inconsistent.

Actually, "correct" DPI only theoretically causes consistency. As a practical matter, the differing number if device pixels required to generate a glyph of some particular physical size typically results in an apparent difference when compared to the same physical size at a different DPI. This is because with the most commonly used fonts each unique pixel size is a physically unique design, not a simple magnification or demagnification of a single design. This is most commonly noticeable in sizes in the vicinity of 16px to 20px. At some point in this range, stem weight changes from 1.00px to 2.00px. Without any applied font smoothing, this is always quite clear. When various smoothing effects are applied, the difference is generally less obvious, but does produce an apparent inconsistency.

Revision history for this message
In , Nick Bowler (nbowler) wrote :

(In reply to comment #21)
> Actually, "correct" DPI only theoretically causes consistency. As a
> practical matter, the differing number if device pixels required to
> generate a glyph of some particular physical size typically results in
> an apparent difference when compared to the same physical size at a
> different DPI.

With correct DPI, 9pt fonts are readable on all my display devices. I
can take a ruler and measure the glyph size, and it is effectively the
same. With incorrect, 96 DPI, 9pt fonts are too small on my laptop to
be legible without a magnifying glass. On a display with non-square
pixels (common on CRTs), the problems are even more pronounced.

While there can obviously be rasterisation differences (the higher
resolution display will look better), this is not merely a theoretical
issue.

(In reply to comment #20)
> It was chosen in order to make display of web pages using Xorg more consistent
> with the way they get displayed on Windows, which by default assumes 96.
> http://blogs.msdn.com/fontblog/archive/2005/11/08/490490.aspx explains the
> origin of 96.

Firefox has the ability to render based on a fixed DPI (which indeed
solves the problem with broken websites not rendering correctly). I'm
not sure why we need the feature in X.org as well. Of course, enabling
that feature makes it impossible to read any text on web pages, but I
suppose that's only a _minor_ inconvenience...

Is the goal of X.org to be bug for bug compatible with Microsoft
Windows?

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #22)

> While there can obviously be rasterisation differences (the higher
> resolution display will look better), this is not merely a theoretical
> issue.

I guess I could have done a better job of making my point. Basically what I meant was because of rasterization differences, there is less practical consistency than ideal, and thus practice in fact falls short of theoretical. Still, the results aren't all that different from ideal, and using actual DPI in practice is much better than an inane assumption of 96 without regard to actual.

> Firefox has the ability to render based on a fixed DPI (which indeed
> solves the problem with broken websites not rendering correctly).

By default, FF uses the greater of actual DPI as reported to it by the environment, or 96. As a practical matter this infrequently makes much difference on web sites, as sites styling in such DPI-dependent physical measurements as mm, in or pt aren't particularly common, and FF's defaults are set in px, which is not affected by DPI.

> I'm not sure why we need the feature in X.org as well.

IMO Xorg has no business making that inane assumption. Nevertheless, there is some rationale to do it that results in some distros doing it, e.g. http://wiki.mandriva.com/en/2009.0_Notes#Font_size_and_physical_DPI

Revision history for this message
In , Nick Bowler (nbowler) wrote :
Download full text (3.5 KiB)

(In reply to comment #23)
> IMO Xorg has no business making that inane assumption. Nevertheless, there is
> some rationale to do it that results in some distros doing it, e.g.
> http://wiki.mandriva.com/en/2009.0_Notes#Font_size_and_physical_DPI

While I cannot complain about the decisions of a distribution that I
don't use (maybe Mandriva users appreciate this), I must address some of
the points on that wiki page:

| ... bizarre results when the DPI detection system fails

Indeed, such as when it decides for some reason to set the DPI to 96
instead of 130+ like it should.

| no desktop environment's interface is yet fully resolution independent

Agreed: Things like the cover art images in my music player are rendered
at a fixed pixel size and are therefore somewhat small. Of course,
lying about the DPI doesn't actually fix this, but it does make it
impossible to correct the problem at the source (e.g. make my music
player display a 3x3 centimetre image instead of a 120x120 pixel image).

| characters could be much larger than the interface elements they are
| supposed to match

I have never, ever seen this. It certainly isn't a problem in any of
the GTK+, Qt, Open Motif or other applications that I use daily
(including applications that don't use any toolkit at all).

| Similar problems often occur on websites

I concede this point. Of course, as hinted above, this could be solved
by setting layout.css.dpi to 96 and disabling any minimum font size in
the default firefox configuration (I don't know if other browsers have
similar parameters). On a high resolution display, the price of this
configuration is that you only get to gawk at pretty layouts instead of
actually reading any information.

Personally, I find the "back" feature of my web browser to be a suitable
means of navigating websites which do not work on my computer.

| ... as many users are accustomed to in Microsoft Windows and Apple OS X

A serious question: How are high resolution displays usable at all on
these operating systems, considering how bad things look on a 135 DPI
when Xorg assumes it's a 96 DPI display? What do they do differently?

| ... can still adjust the DPI value in the KDE or GNOME Control Center,
| or simply increase the default font sizes.

There are two obvious problems with this solution:

1) With hundreds of applications, with different mechanisms for setting
their font sizes, one literally needs to edit dozens of config files to
increase the default font sizes for all programs. In an ideal world,
one would say "I like 9pt fonts for most text" and every program would
use that, but this is sadly not the case today.

2) Even if you fix all the default font sizes, or adjust the DPI value
in the KDE or GNOME Control Center, or with xrandr --fbmm for those who
don't use KDE or GNOME, such that everything's perfect: you have to do
it all over again when you change display devices. It also makes it
impossible to share config files between computers (e.g. an NFS-mounted
home directory).

I don't actually care if the *default* behaviour for Xorg is to use 96
DPI unconditionally. My gripe is that there is no (documented) way to
restore the autodetection (wi...

Read more...

Revision history for this message
In , Arvidjaar (arvidjaar) wrote :

(In reply to comment #24)
> I don't actually care if the *default* behaviour for Xorg is to use 96
> DPI unconditionally. My gripe is that there is no (documented) way to
> restore the autodetection (without patching the server): a config option
> such as the one introduced by my patch solves this issue 100% for me.

May I second it. I am afraid, this discussion took the wrong track (while being quite interesting and exceptionally useful for me personally). It is not about whether 96DPI is better than any other. It is about leaving no choice to configure previous behaviour. That is the real bug.

Revision history for this message
In , Andrey Rahmatullin (wrar) wrote :

(In reply to comment #20)
> It was chosen in order to make display of web pages using Xorg more consistent
> with the way they get displayed on Windows, which by default assumes 96.

Is it an official position of X.org developers? Is it documented anywhere?

Revision history for this message
In , Daniel Stone (daniels) wrote :

On Tue, Feb 16, 2010 at 10:58:07PM -0800, <email address hidden> wrote:
> --- Comment #26 from Andrey Rahmatullin <email address hidden> 2010-02-16 22:58:04 PST ---
> (In reply to comment #20)
> > It was chosen in order to make display of web pages using Xorg more consistent
> > with the way they get displayed on Windows, which by default assumes 96.
>
> Is it an official position of X.org developers? Is it documented anywhere?

Sure, consider it an official position. I don't think it's
unreasonable. Especially if you assume that lower-DPI displays are
likely to be higher-resolution and thus physically huge, meaning that
people sit further away from them, and that displays with a meaningfully
higher DPI are almost always found in phones (as well as some laptops)
these days, meaning that people hold them a great deal closer to their
face.

I do agree that being able to configure the reported DPI (or just Option
"DontForce96DPI") would be entirely useful, but I can't see us changing
anything in the near future, particularly if it breaks web page display.
Saying 'well, don't go to that website then' isn't helpful to anyone at
all, and makes us look like we value strict technical correctness ('but
don't you know what the true definition of a point is?!?') over an
actual working system. While we do value strict technical correctness,
we don't value it to the point of crippling everything else.

Revision history for this message
In , Arvidjaar (arvidjaar) wrote :

(In reply to comment #27)

> I do agree that being able to configure the reported DPI (or just Option
> "DontForce96DPI") would be entirely useful,

So why not just add it (Option "DontForce96DPI") and finish this long thread for good?

Revision history for this message
In , Nick Bowler (nbowler) wrote :

(In reply to comment #27)
> Sure, consider it an official position. I don't think it's
> unreasonable. Especially if you assume that lower-DPI displays are
> likely to be higher-resolution and thus physically huge, meaning that
> people sit further away from them, and that displays with a meaningfully
> higher DPI are almost always found in phones (as well as some laptops)
> these days, meaning that people hold them a great deal closer to their
> face.

As was mentioned earlier in this thread, web browsers such as Firefox do
the Right Thing(tm) by default on lower resolution displays, and don't
need any help from Xorg. Firefox can be configured to do the same thing
for high resolution displays, still without any help from Xorg. I agree
that extremely low resolution displays are very likely to be TVs or
projectors.

> I do agree that being able to configure the reported DPI (or just Option
> "DontForce96DPI") would be entirely useful, but I can't see us changing
> anything in the near future, particularly if it breaks web page display.
> Saying 'well, don't go to that website then' isn't helpful to anyone at
> all, and makes us look like we value strict technical correctness ('but
> don't you know what the true definition of a point is?!?') over an
> actual working system. While we do value strict technical correctness,
> we don't value it to the point of crippling everything else.

When the DPI is falsely set to 96 on a high resolution laptop display,
the result is *NOT* an "actual working system".

Revision history for this message
In , Julien Cristau (jcristau) wrote :

> --- Comment #28 from Andrey Borzenkov <email address hidden> 2010-02-17 04:31:18 PST ---
> So why not just add it (Option "DontForce96DPI") and finish this long thread
> for good?
>
we're waiting for your patch.

Revision history for this message
In , Arvidjaar (arvidjaar) wrote :

(In reply to comment #30)

> we're waiting for your patch.
>

Patch was already posted in comment #17.

Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to comment #29)
> (In reply to comment #27)
> While we do value strict technical correctness,
> > we don't value it to the point of crippling everything else.

> When the DPI is falsely set to 96 on a high resolution laptop display,
> the result is *NOT* an "actual working system".

Arguably it is "working", but "working" isn't _usable_ for many of us with less than perfect vision. cf. bug 26608

Revision history for this message
In , lultimouomo (lultimouomo) wrote :

>Sure, consider it an official position. I don't think it's
>unreasonable. Especially if you assume that lower-DPI displays are
>likely to be higher-resolution and thus physically huge, meaning that
>people sit further away from them, and that displays with a meaningfully
>higher DPI are almost always found in phones (as well as some laptops)
>these days, meaning that people hold them a great deal closer to their
>face.

The problem with fixed dpi is not really with very large screens - you're right, people use them from farther away; not with phones either - I sincerely doubt they use the default X configuration, so they don't really care about this.
It is for laptops, what I would say the majority of the new linux users have - how many student have you seen in a university that use mainly a fixed pc?
With laptops, you can't really choose the distance at which you sit from the screen, you're bound by the keyboard.
Still, laptops and netbooks have greatly varying screen resolutions, from 96dpi to 150 and more.
One size fits all is not going to work here.

>Saying 'well, don't go to that website then' isn't helpful to anyone at
>all, and makes us look like we value strict technical correctness ('but
>don't you know what the true definition of a point is?!?') over an
>actual working system. While we do value strict technical correctness,
>we don't value it to the point of crippling everything else.

When I recalled the definition of point, I did for a reason.
Programs count on that to work correctly, to not show fonts too small to be easily read; to make "100% zoom" even make sense.

At resolution over 130dpi (not rare at all today on portable systems) default fonts get hard to read if you stick to 96 "logical" dpi.

Now, this is not what I'd call an actual working system.

Moreover, if the problem resides in websites, than it must be addressed in browsers. I read that firefox already does this; I don't know if it really does, on Debian it uses system dpi, but then you should file a bug if you think it shouldn't; breaking the browser's more logical behaviour to fix broken web design is a solution, breaking the whole X is not...

The only real argument against using the real screen size is for huge screens, like TV (for projectors the problem doesn't subsist, they don't have an intrinsic screen size.)
I don't even know how many TVs report their real physical size on EDID; I tried only one and it didn't. (As for large computer screens, the most widespread size I see around these days is about 24" 16:9, 1920x1080 points. Which makes a lucky 96dpi, so they don't get hurt whatever the choice.)
Anyway, if you care for the lots of huge LCD owners, you could set a maximum size over which switch to 96dpi.
I ask you again to reconsider your decision.

Revision history for this message
In , Martin-marsark (martin-marsark) wrote :

I have a laptop with 14' LCD 1400x1050 (286mm x 214mm). So screen is very smooth and my correct DPI is about 124x124. Now, with forced 96x96 DPI I have to use very small fonts (DejaVu Sans 7pt) to get reasonable output on this screen.

I think, there should be a freedom in choosing own DPI.

Thanks.

(II) intel(0): Output LVDS1 using initial mode 1400x1050
(II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
(**) intel(0): Display dimensions: (286, 214) mm
(**) intel(0): DPI set to (363, 486)
...
(WW) intel(0): Option "DPI" is not used

Revision history for this message
In , Sascha-web-bugs-freedesktop-org (sascha-web-bugs-freedesktop-org) wrote :

This is really fun on an XO-1 with 200 resp. 267 DPI native resolution...

Revision history for this message
In , Nick Bowler (nbowler) wrote :

(In reply to comment #34)
> I have a laptop with 14' LCD 1400x1050 (286mm x 214mm). So screen is
> very smooth and my correct DPI is about 124x124. Now, with forced
> 96x96 DPI I have to use very small fonts (DejaVu Sans 7pt) to get
> reasonable output on this screen.

If the X server resolution is set smaller than the actual, then fonts
will be smaller than expected, not larger.

> (**) intel(0): DPI set to (363, 486)

This looks to me like a different problem: your log shows the resolution
being set to a phenomenally huge (and not even square) value.

Revision history for this message
In , Martin-marsark (martin-marsark) wrote :

(In reply to comment #36)

> > (**) intel(0): DPI set to (363, 486)
>
> This looks to me like a different problem: your log shows the resolution
> being set to a phenomenally huge (and not even square) value.
>
I think that this line is some nonsense. But, how to force correct resolution without DPI option in the xorg.conf?

Revision history for this message
In , Nick Bowler (nbowler) wrote :

(In reply to comment #37)
> But, how to force correct resolution without DPI option in the
> xorg.conf?

For non-xrandr-1.2 drivers, one can use DisplaySize [width] [height] option
in xorg.conf. For xrandr-1.2 drivers, one can use xrandr --fbmm
[width]x[height] after starting the server, but before starting any other
clients. In either case, [width] and [height] are set in millimetres.

Revision history for this message
In , Michal Suchanek (hramrach) wrote :

(In reply to comment #6)
> The 'screen size' as reported in the core protocol now respects the DPI value
> given by the user or config file and ignores the actual monitor DPI of any
> connected monitor.
>
> The real monitor size is reported through the RandR extension if you really
> need to know the physical size of the display.
>
> This is intentional and follows the practice seen in many other desktop
> environments where the logical DPI of the screen is used as an application and
> font scaling factor.

Yes, and the default font size should be set to match the screen resolution, as is the practice in many other desktop environments.

Note that even on Windows that completely ignore actual screen DPI the system integrators do preset the font scaling factor to approximately match the actual DPI.

>
> If you don't like it, you're welcome to configure the X server to taste; we
> haven't removed any of those knobs. And, you can even use xrandr to change

You just set them intentionally to the wrong value. Thank you very much.

Revision history for this message
In , Julien Cristau (jcristau) wrote :

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

Changed in xorg-server (Ubuntu):
status: New → Incomplete
importance: Undecided → Low
Anders Kaseorg (andersk)
Changed in xorg-server (Ubuntu):
status: Incomplete → Confirmed
Changed in xorg-server:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server:
importance: Unknown → Medium
tags: added: regression-release
Changed in xorg-server:
status: Confirmed → Invalid
Anders Kaseorg (andersk)
Changed in xorg-server:
importance: Medium → Unknown
status: Invalid → Unknown
Changed in xorg-server:
importance: Unknown → Wishlist
status: Unknown → Confirmed
32 comments hidden view all 112 comments
Revision history for this message
In , Pander (pander) wrote :
Revision history for this message
In , Tfa7 (tfa7) wrote :

(In reply to comment #14)
> See also https://help.ubuntu.com/community/AsusZenbook#LCD
Heh, UX31A I'm typing this at has 166 dpi.

Those who forced the 96dpi kludge into xorg should be forced to walk in my shoes till the end of their lives with no chance to change those.

Revision history for this message
In , Public-y (public-y) wrote :

See http://pastebin.com/vtzyBK6e for #xorg-devel discussion about this.

Revision history for this message
In , Tfa7 (tfa7) wrote :

(In reply to comment #16)
> See http://pastebin.com/vtzyBK6e for #xorg-devel discussion about this.
Some comments:

> <ohsix> not a lot of people are bothered, since getting the per display dpi
> right is a hard problem, even if you can set it for one single monitor in
> particular, 'fixed' is handling some difference in dpi across displays,
> which doesn't happen in the toolkits or anything

Wrong. *I* am bothered, and *I* operate a few dual-monitor setup including those with different display DPI. That ohsix windows migrant would have a hard time telling me that forcing DPI to a semi-arbitrary value to follow the obsolete windows suit is right (and that it is worth breaking what used to work since last century).

> <ohsix> maybe you misunderstood me, i was telling you what's expected to do it

By whom? Those who smoked windows crack and a gazillion of tray notifiers?

Thanks but no thanks. I've seen enough weird video hardware (e.g. Acer V550 monitors reported those funny EDID values) but those are rather *exceptions* to be handled, and one can even automate that -- if a display has DPI less than e.g. 30 or higher than e.g. 300 (as of today) then it might be treated as a reason to fall back to default (96 is ok here) since those who operate special cases *can* be expected to know their ways around hi-res displays or display walls.

> <ohsix> any cobbled together thing where nobody really cares
> is going to miss details like that

This bastard should not continue to erode free software. *He* doesn't care.

Seems that Red Hat has hired too many dumb morons who took their windows habits and attitude there, see also http://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2012-12-13 /fedora -- and recall the F12 PackageKit saga of Richard Hughes "fame": https://bugzilla.redhat.com/show_bug.cgi?id=534047#c9

PS: just in case, I'm using and developing free software since 1998 and have done numerous migrations for people and companies. I know that care *is* crucial. Good luck to Xorg team with preserving that.

Revision history for this message
In , Felix Miata (mrmazda) wrote :
Download full text (3.5 KiB)

More from that IRC conversation:
<alesguzik> I'm not asking about making it default, but when screen size can be detected and resolution is known, what is the problem with dpi?
<alesguzik> It worked at some point in the past
<ohsix> it never worked

Ohsix's definition of "never" must be different from the dictionary's. As alesguzik said, automatically matching DPI to display density did work in the past:

$ cat /etc/SuSE-release
openSUSE 10.2 (i586)
VERSION = 10.2
$ head -n15 /var/log/Xorg.0.log | tail -n6
X Window System Version 7.1.99.902 (7.2.0 RC 2)
Release Date: 13 November 2006
X Protocol Version 11, Revision 0, Release 7.1.99.902
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux m7ncd 2.6.18.8-0.10-default #1 SMP Wed Jun 4 15:46:34 UTC 2008 i686
Build Date: 02 June 2008
$ grep Output /var/log/Xorg.0.log | egrep -v 'disconnected|no monitor'
$ grep -v ^\# /etc/X11/xorg.conf.d/50-monitor.conf | grep DisplaySize
grep: /etc/X11/xorg.conf.d/50-monitor.conf: No such file or directory
$ grep -v ^\# /etc/X11/xorg.conf | grep DisplaySize
$ grep -v ^\# /etc/X11/xorg.conf.d/50-monitor.conf | grep PreferredMode
grep: /etc/X11/xorg.conf.d/50-monitor.conf: No such file or directory
$ grep -v ^\# /etc/X11/xorg.conf | grep PreferredMode
$ xrdb -query | grep dpi
$ xdpyinfo | egrep 'dime|ution'
  dimensions: 1600x1200 pixels (402x302 millimeters)
  resolution: 101x101 dots per inch
$ xrandr | head -n5
 SZ: Pixels Physical Refresh
*0 1600 x 1200 ( 402mm x 302mm ) *85 75 70 65 60
 1 1400 x 1050 ( 402mm x 302mm ) 75 60
 2 1280 x 960 ( 402mm x 302mm ) 85 60
 3 1152 x 864 ( 402mm x 302mm ) 75

more Xorg.0.log excerpts:
(II) RADEON(0): EDID data from the display on port 1 ----------------------
(II) RADEON(0): Manufacturer: NEC Model: 61da Serial#: 5356
(II) RADEON(0): Year: 2002 Week: 39
(--) RADEON(0): Virtual size is 1600x1200 (pitch 1664)
(**) RADEON(0): *Default mode "1600x1200": 229.5 MHz, 106.2 kHz, 85.0 Hz
(--) RADEON(0): Display dimensions: (400, 300) mm
(--) RADEON(0): DPI set to (101, 101)
$ xrandr -v
Server reports RandR version 1.1

$ cat /etc/SuSE-release
openSUSE 10.2 (i586)
VERSION = 10.2
$ head -n15 /var/log/Xorg.0.log | tail -n6
X Window System Version 7.1.99.902 (7.2.0 RC 2)
Release Date: 13 November 2006
X Protocol Version 11, Revision 0, Release 7.1.99.902
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux m7ncd 2.6.18.8-0.10-default #1 SMP Wed Jun 4 15:46:34 UTC 2008 i686
Build Date: 02 June 2008
$ grep Output /var/log/Xorg.0.log | egrep -v 'disconnected|no monitor'
$ grep -v ^\# /etc/X11/xorg.conf | grep DisplaySize
$ grep -v ^\# /etc/X11/xorg.conf | grep PreferredMode
$ xrdb -query | grep dpi
$ xdpyinfo | egrep 'dime|ution'
  dimensions: 1920x1440 pixels (403x302 millimeters)
  resolution: 121x121 dots per inch
$ xrandr | head -n5
 SZ: Pixels Physical Refresh
*0 1920 x 1440 ( 403mm x 302mm ) *75 60
 1 1856 x 1392 ( 403mm x 302mm ) 75 60
 2 1792 x 1344 ( 403mm x 302mm ) 75 60
 3 1600 x 1200 ( 403mm x 302mm ) 85 75 70 65 60
$ xrandr -v
Server reports RandR version ...

Read more...

Revision history for this message
Sergio Callegari (callegar) wrote :

I may not agree with the tone that appears a bit aggressive, but the observations by Tfa7 appear to be correct.

Furthermore, with reference to the justification that there are monitors that report wrong/crazy EDID values, I really do not think that the majority of users who have bought and paid properly working monitors should suffer from others' broken hardware by having their system ignore the correct EDID info that their monitors can report.

Given the discussion of the xorg developers, I really think that this should be fixed downstream or (temporarily) in a PPA.

And it should be done *quickly*, since things like newer Apple machines with retina displays, Google's Chromebook Pixel, Toshiba's Kirabook, newer Sharp's displays at 11.6", 14", and 15.6" (235-262 PPI), Sharp's 13.3" display (221 PPI), Samsung's newer 13.3" displays (276 PPI) and tons of newer high-end displays will be all badly broken by the hardwired 96dpi setup.

Please rise the priority accordingly to this new wave of hardware.
And if possible, have someone remove the wishlist status on the freedesktop bug tracker, since this looks more like a regression.

Revision history for this message
In , Sergio Callegari (callegar) wrote :

Please remove the "enhancement" status. This used to work and now it is not working anymore, thus it is a regression.

Also note that the experience on all newer high end hardware by Apple, Sharp, Samsung, Google (for instance see http://www.macrumors.com/2013/05/20/samsung-and-sharp-introduce-new-ultra-high-resolution-notebook-displays/) is broken by the hardwired 96dpi.

Revision history for this message
In , Tfa7 (tfa7) wrote :

It dawned on me that a "proposed replacement" might lack such an, um, "feature" of hardwired 96 dpi. Now if that will be called progress I'll invest some time into finding those who arranged that and ruining their remnants of reputation.

(creating and improving is vastly more important but the feeling of impunity results in *evil* things, unfortunately)

Folks, hey let's just get this crap fixed, are you still listening to the community? XFree86 project used to skip that at times, please don't.

Revision history for this message
Bachi (m-bachmann) wrote :

I would assume that by now a great deal of people do have a hi-res display and are affected. This bug should receive highest priority, certainly over feature enhancements as it ruins the experience.

Revision history for this message
Scott Shawcroft (scott-shawcroft) wrote :

I too thing this should be fixed. The best argument I see for it is that at least Gentoo tells you to rely on autodetection of the settings. There was a time where you could generate an xorg.conf and then tweak it but we've progressed past it because the config always broke. Now, requiring someone to fall back xorgr.conf is just silly.

Revision history for this message
madbiologist (me-again) wrote :

I'm not sure if this is being worked on for the Unity desktop in Ubuntu, but you might like to try the Ubuntu GNOME 14.04 "Trusty Tahr" beta 1 which is based on GNOME 3.10 - see https://wiki.ubuntu.com/TrustyTahr/Beta1/UbuntuGNOME for info and download links. As per https://help.gnome.org/misc/release-notes/3.10/more-core-ux.html.en GNOME 3.10 includes High-Resolution Display Support. Further improvements are coming to the GNOME Shell in GNOME 3.12 which is scheduled for release in March or early April - see http://www.phoronix.com/scan.php?page=news_item&px=MTYwMjE

Revision history for this message
Tom Fields (udzelem) wrote :

This should definitely be fixed for Ubuntu 14.04 (Trusty).

This is NOT a wishlist item, this is a BUG.
Using a default DPI of 96 on a 200 DPI monitor is /NOT/ helpful at all!

Revision history for this message
madbiologist (me-again) wrote :

A couple of last minute HiDPI fixes have just been added to GNOME shell 3.12.

More relevantly, Unity 7 on Ubuntu 14.04 "Trusty Tahr" will have support for HiDPI displays.

Revision history for this message
Sergio Callegari (callegar) wrote :

Thanks for the info! However, let me recall that the bug is not against unity and gnome, but xorg. For many reasons one may have X starting without unity or gnome (because of using another desktop or a transient misconfiguration). In this case, X should be able to provide readable chars even if one is on a hi-dpi monitor. X setting the DPI at 96 prevents this. Please, even if gnome and unity fix the HiDPI issue, let still have a configuration option for X allowing one to switch between:
1) Ignore the EDID and fix the dpi to 96 (current behavior, good for older hardware)
2) Respect the EDID info about dpi (good for newer hardware, but risky for projectors and TVs)
3) Respect the EDID info, with same safety checks (e.g. force some default if EDID data looks too small or too large to be credible)

Revision history for this message
madbiologist (me-again) wrote :

Fair point. Unfortunately from what I can see the xorg developers are not interested in fixing this and believe that the current behaviour is both correct and acceptable. Some of them seem to be suggesting that it is the job of the window manager/desktop environment to pass the desired settings to xrandr after receiving the monitor config from xrandr. When and if they change their mind we might be able to close this bug. In the meantime I thought I might pass on some more info...

Ubuntu developers are planning HiDPI support for the Ubuntu Linux boot experience - when dealing with GRUB2's boot-loader menu and the Plymouth boot splash screen. They are also investigating HiDPI support for Linux virtual consoles. Specifically, "Developers at this week's vUDS session will be working on a 2x version of the GRUB2 font for basic HiDPI support by just appearing twice as big, working on GRUB2 support for returning a display's physical dimensions, work out support for a scaling factor within Ubuntu's Plymouth theme, and support for a scaling factor within the console-setup font configuration."

There is also bug #1292218 which is described as "The lockscreen has correct Panel HiDPI support, but the prompt doesn't scale right now."

Some of this work might be ready for Ubuntu 14.04 "Trusty Tahr" but it is unlikely that all of the HiDPI improvements will be ready for that release.

Revision history for this message
In , Pander (pander) wrote :

Here are recent update https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/589485 but this bug hasn't been touched for over a year. Could someone provide an update on the status?

Revision history for this message
Michael Shigorin (shigorin) wrote :

> Could someone provide an update on the status?
Upstream insists on keeping xorg broken along winxp lines; I wouldn't be surprised if they "fix" it in wayland some day, years after winvista and ages after it worked in X. I'd call this "$name_that_sexual_minority default" based on the methods used to push it :-/

Revision history for this message
In , Tfa7 (tfa7) wrote :

ping

Revision history for this message
Sergio Callegari (callegar) wrote :

A couple more notes.

IMHO, the biggest issues with the current situation are the following:

1) The physical display size is available via xrandr. However xrandr delivers it in a format that is rather uncomfortable to parse.
2) The hardware only provides a physical display size and not the expected viewing distance. However, only with the *two* ingredients one can reliably compute a good 'virtual' dpi value to pass to the applications in order to get correctly sized fonts, icons and graphical elements.
3) When it is the desktop environment (DE) alone to decide the dpi value rather than xorg, there is always the risk of getting an unusual working environment when the user: (i) tests a different DE; (ii) has issues with the DE at DE startup. For these reasons, it would be good to have xorg provide a sane environment even before the DE starts.
4) For some reason some java apps seem to ignore the dpi value set by the DE. I'm told that matlab is among them.

So, please:
1) in the short sun re-introduce the xorg patch with the switch that lets one control whether the system should pick the EDID dpi or not as the NVIDIA driver does.
2) in the long run, it may make sense to have some heuristics in place capable of guessing if a monitor is a desktop monitor (normal viewing distance), a TV (larger than normal viewing distance), a projector (larger than normal viewing distance /and/ screen size that may vary depending on distance) or a pad (smaller than normal viewing distance and small screen).

Revision history for this message
Sergio Callegari (callegar) wrote :

I would also add that in the case of multiple screens with different features (e.g. laptop screen + desktop monitor), it would be great to have different dpi values and apps notified of the dpi change when they are moved from one screen to another.

Revision history for this message
toothbrush (s-baul-s) wrote :

Argh. I am yet another hapless user clamouring for help.

My hardware: Apple MacBook 13" Retina, DPI of 227.
X.Org's infinite wisdom: DPI of 96.

My eyes are now broken, and i find myself tweaking individual apps in the hope that they'll become usable. Inevitably, proportions become crooked.

Please please please give us the ability to set DPI to native!

Revision history for this message
In , Igpg (igpg) wrote :

https://bugs.freedesktop.org/show_bug.cgi?id=89820 All the information you need for what's happening on my FullHD 15.6"

And I do not agree this to be an "enhancment" as you are forced to use LXDE (Which is the only one it will respect your HARD WORK ON SETTING THE DPI AND DIMENSION) while all the other DE's / WM's will ignore that (As it's supposed Xorg is getting the "right" dimension DPI) and After that you must search and look up how to force Firefox, Mozilla, Skype (not supported) Chromium (Not supported) Pidgin, etc, etc applications which will just ignore the Operating system set DPI.

That's not at all an enhancment!

Changed in xorg-server:
importance: Wishlist → High
Pander (pander)
tags: added: 16.04 xenial
5 comments hidden view all 112 comments
Revision history for this message
In , Main-haarp (main-haarp) wrote :

I too would like Xorg to not blatantly lie.

The proposed patch from 2011 does not apply anymore to recent versions, is there an updated one?

Revision history for this message
In , Thomas-mercier (thomas-mercier) wrote :

I am out of the office during the week of January 25th with very limited access to email.

Revision history for this message
In , Michal Suchanek (hramrach) wrote :

This seems to work for me.

X.Org version: 1.17.2
resolution: 100x100 dots per inch

Actual resolution seems to be more like 109 dpi but it's certainly not fixed at 96.

6 comments hidden view all 112 comments
Revision history for this message
Václav Šmilauer (eudoxos) wrote :

@Sergio, sorry but your comments are OT. Different resolutions for different screens are not supported on the toolkit level; a window can be on both screens at once and such, and it is beyond the scope of this bug. Viewing distance again has nothing to do with this bug; DPI does not depend on the viewing distance, it simply expresses physical dimensions (lengths) of one pixel; length does not depend on distance (I am a physicist, I know that one for sure). Of course for guessing comfortable font size for reading, viewing distance is important, but that is an entirely different problem, although it actually required a valid value of DPI.

7 comments hidden view all 112 comments
Revision history for this message
In , Václav Šmilauer (eudoxos) wrote :

@Michal: I have also 1.17.2 and reported DPI is still 96x96, even though the actual resolution is 174x171 (see https://bugs.launchpad.net/bugs/1512606 for details).

6 comments hidden view all 112 comments
Revision history for this message
Sergio Callegari (callegar) wrote :

Thanks for your observations.

In fact, in my comments there were multiple points.

One of them is different DPI for different screens. As you mention, this cannot be more than a wish for now, as Linux is very badly lagging wrt windows that has been enjoying per-display DPI settings for more than 2 years now, since Windows 8.1 (see https://blogs.windows.com/windowsexperience/2013/07/15/windows-8-1-dpi-scaling-enhancements/). Clearly, for MS developers the idea was that no one uses applications halfway between screens unless they are on very specific arrangements (e.g. screen walls) where all screens have homogeneous properties. But rightly, to lag is not a bug. Still, I hoped that the 'wishlist' nature of my comment #92 was clear and I thought that "wishlist item" != "off topic item". In this respect, I am quite curious of how Ubuntu touch will deal with the matter when the convergence thing is finally in place, since apps will need to be seamlessly movable from a pad screen with >400 dpi to a display with <100 dpi and remain readable.

For the other comment #91, you are once again right on a formal point of view. DPI is just a physical property of the screen. As a matter of fact, from a similarly formal point of view, it is a property that projectors do not have at all, unless you consider the projection distance, since for projectors DPI depends on the latter. Please, s/viewing distance/projecting distance/ in my post if you prefer. Quite evidently, the concept of modelling screen with their physical DPI in graphical environments roots in times when the screen could be only a big box with a CRT placed on a desk at about 50cm from the viewer. Indeed, in the 80s I was perfectly happy with it. Now, with the large variety of devices used for display, the concept is already being stretched a little (at least to accommodate for projectors for which the physical DPI does not exist independently of the projecting setup). In my view, physical DPI is a concept that is mostly critical for screen manufacturers. For a graphical environment designer, the ultimate goal is being able to deliver readable text and images on the screen and what should count is 'perceived dpi' that is more or less the dpi projected on the viewer retina. This is a concept that could be also expressed using DPD (dots per degree) and working in an angular fashion. Again, I totally agree that making the system aware of user perception is nothing more than a wishlist item at the time being.

It is worth mentioning that at the time I commented, the bug status was precisely "wishlist".

For the other points in my post, I cannot not see 1) - 4) in #91 (as well as the 'in the short term' conclusion) can be off-topic, as they pointed out practical problems and suggested an operative (though short term and suboptimal) solution.

Obviously, I agree that this is not a very important bug, since people have happily coped with it for the past 6 years. In the end, coping with it is as easy as using NVIDIA hardware with the proprietary driver or recompiling xorg with the DPI patch that had been floating around since 2010 (in the end, this is one of the reasons why open source exists).

Revision history for this message
Václav Šmilauer (eudoxos) wrote :

There is 62 people who think this bug *is* important. It is a problem mainly with displays of which DPI is far from 96x96, such as more and more common HiDPI.

Let's not turn it into discussion forum on Linux vs. Windows, or ideal state of Linux. We simply want Xorg to respect the DPI reported by EDID.

Revision history for this message
Sergio Callegari (callegar) wrote :

Yes. As mentioned it is a single patch to apply, that has been available since the very first day the bug was reported, actually 8 years ago (I was wrong when I said 6). Incidentally, I was the second reporter of this issue, with Bug #572943, the second lowest numbered duplicate, one month before the bug that is hosting this discussion was opened. I started saying that the bug needed a higher priority in 2013. So, please, do not enter a discussion with a long history just to label things and be aggressive, rather start asking why that single patch remained not applied for 6-8 years.

Just to recall some history, the issue began with the use of EDID information for DPI being *intentionally* removed upstream, for many reasons including adhering to what other OSs used to do at that time. When some other people and I started insisting to have the feature restored at least in ubuntu, there was resistance. Resistance was partially justified (e.g. on the upstream lists, see https://bugs.freedesktop.org/show_bug.cgi?id=23705 "CLOSED" as "NOT A BUG") by the consideration that merely reintroducing the feature was not enough and that a better vision for managing the growing variety of display types (including hi-dpi) was needed. This is why considerations on the approaches taken by other OSs and on long term desiderata started being discussed alongside the short term solutions.

Revision history for this message
Berte (berte) wrote :

Hi All,

I'm jumping in this thread because I think this 'bug' is the source of many scaling issues.

I'm the owner of a 13" laptop with a 3200x1800 native resolution. As recommended elsewhere, I set the scale factor to 2 and most applications are readable now. However, readable is does not mean correct.

Using 3 different tools, I get 3 different DPI. See below:

>get-edid | parse-edid
Section "Monitor"
 Identifier ""
 ModelName ""
 VendorName "SDC"
 # Monitor Manufactured week 0 of 2014
 # EDID version 1.3
 # Digital Display
 DisplaySize 290 170
 Gamma 2.20
 Option "DPMS" "true"
 Modeline "Mode 0" 361.31 3200 3248 3280 3316 1800 1802 1807 1816 -hsync -vsync
 Modeline "Mode 1" 361.31 3200 3248 3280 3680 1800 1802 1807 2045 -hsync -vsync
EndSection

=> The above info results in about 280 DPI.

>xrdb -query | grep dpi
Xft.dpi: 192

>xdpyinfo | grep -B2 resolution
screen #0:
  dimensions: 3200x1800 pixels (846x476 millimeters)
  resolution: 96x96 dots per inch

4 comments hidden view all 112 comments
Revision history for this message
In , Felix Miata (mrmazda) wrote :

(In reply to Michal Suchanek from comment #26)
> This seems to work for me.

Are you sure nothing is setting DPI explicitly or implicitly, such as your DE?

> X.Org version: 1.17.2
> resolution: 100x100 dots per inch

> Actual resolution seems to be more like 109 dpi but it's certainly not fixed
> at 96.

Using which video driver? All FOSS driver versions I've used since long before this bug was opened force 96 unless unless explicitly overridden via xrandr, Xft.dpi, server startup option -dpi, DE settings (which typically use Xft.dpi or xrandr), or xorg.conf*'s DisplaySize option. All these options force a specific DPI. None enable the server or driver to do what computers do best, calculate and apply an accurate value automatically, which is what this bug is effectively requesting.

Pander (pander)
tags: added: yakkety
removed: 16.04
Revision history for this message
Ztirfe Elgnid (z-figura12) wrote :

Hi. This bug^H^H^H"feature" is now over nine years old. As much as I'd like to see a proper solution, I think it would really be best at this point to at *least* add the patch given while we wait for that to happen. Pretty please?

1 comments hidden view all 112 comments
Revision history for this message
In , Alan Coopersmith (alan-coopersmith) wrote :

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

Revision history for this message
In , Tfa7 (tfa7) wrote :

FWIW we've patched xorg-server in the distribution.
Shame on those breaking base functionality instead of fixing their crap!

Revision history for this message
In , Main-haarp (main-haarp) wrote :

(In reply to Michael Shigorin from comment #30)
> FWIW we've patched xorg-server in the distribution.
> Shame on those breaking base functionality instead of fixing their crap!

Do you happen to have a more recent patch? The ones posted here are very outdated.

Revision history for this message
In , Tfa7 (tfa7) wrote :

(In reply to main.haarp from comment #31)
> Do you happen to have a more recent patch?

1.19.3: http://git.altlinux.org/gears/x/xorg-server.git?p=xorg-server.git;a=commitdiff;h=c5b77a90d7e0d6a1874fcb545969f355d1ed0293

Revision history for this message
In , Main-haarp (main-haarp) wrote :

(In reply to Michael Shigorin from comment #32)
> (In reply to main.haarp from comment #31)
> > Do you happen to have a more recent patch?
>
> 1.19.3:
> http://git.altlinux.org/gears/x/xorg-server.git?p=xorg-server.git;
> a=commitdiff;h=c5b77a90d7e0d6a1874fcb545969f355d1ed0293

Applies well. Thanks!

4 comments hidden view all 112 comments
Revision history for this message
Václav Šmilauer (eudoxos) wrote :
5 comments hidden view all 112 comments
Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/253.

Changed in xorg-server:
status: Confirmed → Unknown
Displaying first 40 and last 40 comments. View all 112 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.