Bug 692

Summary: xrandr resolution changes incorrectly affect server DPI settings
Product: xorg Reporter: Dan Berger <dberger>
Component: Server/Ext/RandRAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high CC: anselm, caster, ccshan, hramrach
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard: 2011BRB_Reviewed
i915 platform: i915 features:
Attachments:
Description Flags
Output of script running xrandr repeatedly
none
a script which rapidly reduces DPI in dual screen setup
none
xrandr output
none
xdpyinfo output none

Description Dan Berger 2004-05-30 07:20:25 UTC
From: 	Dan Berger <dberger _at_ oubliette _dot_ org>
To: 	keithp _at_ keithp _dot_ com
Cc: 	agd5f _at_ yahoo _dot_ com
Subject: 	xrandr dpi question
Date: 	Fri, 28 May 2004 13:25:22 -0700
Mailer: 	Ximian Evolution 1.5.6 (1.5.6-04192004) 	

Greetings.  Sorry for the email out of the blue, I've done a fair bit of
googling to see if this is question has been asked and answered, but
come up blank.

I'm curious about a behavior I'm observing when using XrandR to change
resolutions.  I'm using a notebook with a radeon chip, and the
"MergedFB" driver modifications by Alex Deucher (who I've cc'd on this
message).  (On the off-chance MergedFB doesn't ring any bells, it's
essentially a single frame-buffer spanning both card outputs, aka
TwinView in nvidia-speak).  

When I have an external monitor attached I want to run in 2048x768
(spanning the LCD and external monitor), and when I'm using only the
LCD, I want 1024x768.

xrandr does this, but I've seen some strange behavior in some
applications - especially emacs, ghostview, and openoffice.  I've
narrowed it down to the fact that xrandr is changing the dpi settings
for the X server - and I'm wondering why this is the right thing to do.

The "default" X mode is 2048x768, and xdpyinfo reports:

resolution: 75x75 dots per inch

if I xrandr to 1024x768, and re-run xpdyinfo, it reports

resolution: 35x75 dots per inch

Many applications aren't affected (those based on GTK, for example, seem
immune) but not being an X hacker, it's not obvious why this dpi
adjustment is, in general, the right thing to do.  I'm guessing that it
has to do with the fact that in the MergedFB case the physical
dimensions of the "screen" are changing - but xrandr doesn't realize
that.  (I also figured it might be a driver problem, which is part of
why I'm cc'ing Alex.)

If you'd be so kind, I'd appreciate any thoughts you have on the
subject.

Cheers.

--- Response ---

From: 	Keith Packard <keithp _at_ keithp _dot_ com>
To: 	Dan Berger <dberger _at_ oubliette _dot_ org>
Cc: 	keithp _at_ keithp _dot_ com, agd5f _at_ yahoo _at_ com
Subject: 	Re: xrandr dpi question
Date: 	Fri, 28 May 2004 13:28:10 -0700
Mailer: 	exmh version 2.3.1 11/28/2001 with nmh-1.1


Around 13 o'clock on May 28, Dan Berger wrote:

> it's not obvious why this dpi
> adjustment is, in general, the right thing to do.

It isn't; it's just a bug in the XFree86 DDX implementation of Xrandr.

-keith
Comment 1 Grant Likely 2004-11-21 12:52:33 UTC
I'm having exactly the same issue with xorg 6.8.0.  Has there been any progress
on this issue?
Comment 2 Daniel Stone 2007-02-27 01:23:35 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 3 Rolf Leggewie 2007-07-22 17:13:08 UTC
Is this still an issue for you guys?  I guess there was quite a bit of progress since 2004.  FWIW, it works fine for me.
Comment 4 Vlastimil Babka 2007-07-26 05:52:38 UTC
I think I have a related problem, not with resolution but rotation which breaks DPI, affecting the font sizes of programs I start up when broken. Further rotating can fix it back again, then break again, see:

Starting in normal (1680*1050):
 $ xdpyinfo | grep dots
  resolution:    94x95 dots per inch
 $ xrandr -o left
 $ xdpyinfo | grep dots
  resolution:    95x94 dots per inch
 $ xrandr -o normal
 $ xdpyinfo | grep dots
  resolution:    152x59 dots per inch
 $ xrandr -o left
 $ xdpyinfo | grep dots
  resolution:    59x152 dots per inch
 $ xrandr -o normal
 $ xdpyinfo | grep dots
  resolution:    94x95 dots per inch

and so on.
I have xorg-server-1.3.0.0, libXrandr-1.2.1, xrandr-1.2.2
Comment 5 Michal Suchanek 2008-11-18 08:24:33 UTC
This seems similar to bug  5953
Comment 6 Jerome Glisse 2009-06-30 07:09:39 UTC
Do you still have this issue with recent Xorg & ddx driver ?
Comment 7 Michal Suchanek 2009-06-30 09:04:03 UTC
Created attachment 27266 [details]
Output of script running xrandr repeatedly

Still a problem with X 1.4.2

1.6 does not work on this hardware.
Comment 8 Michal Suchanek 2009-06-30 09:08:11 UTC
*** Bug 18615 has been marked as a duplicate of this bug. ***
Comment 9 Michal Suchanek 2010-04-24 19:04:36 UTC
Created attachment 35274 [details]
a script which rapidly reduces DPI in dual screen setup

I can still break DPI on X server 1.7
X.Org X Server 1.7.6
Release Date: 2010-03-17
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.26-2-amd64 x86_64 Debian
Current Operating System: Linux heretic 2.6.34-rc4-amd64 #2 SMP Tue Apr 13 13:22:12 CEST 2010 x86_64

I can't quite see how the DPI can be different in the same mode - it should be calculated from the actual screen configuration to get consistent results.
Comment 10 Michal Suchanek 2010-04-24 19:05:49 UTC
Created attachment 35275 [details]
xrandr output
Comment 11 Michal Suchanek 2010-04-24 19:07:56 UTC
Created attachment 35276 [details]
xdpyinfo output
Comment 12 Jeremy Huddleston Sequoia 2011-09-25 15:58:43 UTC
Is this still an issue with recent deliverables (xorg-server-1.11.x, recent 
drivers, etc)?
Comment 13 GitLab Migration User 2018-12-13 18:33:16 UTC
-- 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/222.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.