Bug 41115

Created attachment 51560 [details] [review]
Patch rebased against current git.

Since the original patch no longer applies to current master, and I've had an
updated patch lying around for some time, I'm posting it here so it doesn't get
lost.  It seems to still work but it's only been lightly tested.

I no longer care about this issue, since the available solutions are sufficient
for me.  I'll leave the rest to the people who do care.

Cheers.

I renamed the option to match comment #27 https://bugs.freedesktop.org/show_bug.cgi?id=23705#c27 in #27505: DontForce96DPI.  There are Fedora 15 i386 and x86_64 rpms at: http://koji.fedoraproject.org/koji/taskinfo?taskID=3372856 and of course the source rpm.

I tested it and actually didn't see what I expected, so I'm not sure what's going wrong:

$ rpm -q xorg-x11-server-Xorg                                                                                         
xorg-x11-server-Xorg-1.10.4-1.3.fc15.x86_64
$ grep -C2  Dont /etc/X11/xorg.conf
Section "ServerFlags"
        Option      "AIGLX" "on"
        Option      "DontForce96DPI" "on"
EndSection

$ xrandr|grep LV
LVDS connected 1366x768+0+0 (normal left inverted right x axis y axis) 293mm x 164mm
$ xdpyinfo|grep dimens
  dimensions:    1366x768 pixels (361x203 millimeters)

I rebased Nick's original patch but I don't think I ended up with something any different than his most recently-posted, rebased patch.

Created attachment 51580 [details] [review]
Patch rebased against Fedora 15's xorg-x11-server-Xorg

the manpage change is in a separate patch because of how Fedora's rpm applies the patches, but that change is irrelevant for the detection/setting of DPI.

I'm not a coder, so this could be totally off the wall, but I wouldn't expect to 'Option      "DontForce96DPI" "on"' to be a server flag, but rather a Monitor option. Then again 'Option      "TargetRefreshRate" "60"'' as a Monitor option hasn't been working for me at least since 1.9.3, maybe ever, so maybe the problem you see is not related to the patch itself.

Created attachment 51582 [details] [review]
patch rebased against Ubuntu 1.10.4 package + add option to set the defalt DPI value

This patch works for me. When I set DefaultDPI to auto I get 86 DPI on my 15" screen. Somewhat odd is that setting DefaultDPI to 123 gives 124 DPI on my 17" screen.

(In reply to comment #4)
> I'm not a coder, so this could be totally off the wall, but I wouldn't expect
> to 'Option      "DontForce96DPI" "on"' to be a server flag, but rather a
> Monitor option. Then again 'Option      "TargetRefreshRate" "60"'' as a Monitor
> option hasn't been working for me at least since 1.9.3, maybe ever, so maybe
> the problem you see is not related to the patch itself.

Would it be good to mirror what nvidia's already using?  I know their driver called it "UseEDIDDPI", but I don't recall what Section it went in.

(In reply to comment #5)
> Created an attachment (id=51582) [details]
> patch rebased against Ubuntu 1.10.4 package + add option to set the defalt DPI
> value
> 
> This patch works for me. When I set DefaultDPI to auto I get 86 DPI on my 15"
> screen. Somewhat odd is that setting DefaultDPI to 123 gives 124 DPI on my 17"
> screen.

Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>

Please send the patch to the xorg-devel mailing list for more eyes.

Removing blocker status.  While this will likely land in 1.12, it won't block it.

Are there any progress on this patch? I will probably give my laptop to the dev who not allowing this patch to upstream, he should burn his eyes with it.

Any updates on this? Original bugreport was filled almost 3 years ago.

Current behavior is really annoying on laptops + external displays....

May the so called developers with "I know better" attitude be treated by physicists with the same attitude!

They broke the thing for BUG compatibility with an obsolete piece of crap for a single use case already handled in corresponding application (a web browser), they told us to go sink in the mailing lists and now they are too busy to at least accept the knob.

Folks, hallo!  Anyone there?  Or everyone reading mail on a low DPI 64" plasma?

Does anyone work on this?

Patch has been posted here and on the xorg-devel list.

Feel free to rebase/resend/nag somebody with commit access until it's applied.

See also https://help.ubuntu.com/community/AsusZenbook#LCD

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

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

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

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 1.1

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 1920x1440 (pitch 1920)
(**) RADEON(0): *Default mode "1920x1440": 297.0 MHz, 112.5 kHz, 75.0 Hz
(--) RADEON(0): Display dimensions: (400, 300) mm
(--) RADEON(0): DPI set to (121, 121)

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.

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.

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?

ping

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!

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?

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

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.

@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).

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

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

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

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

(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

(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!

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