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
I'm having exactly the same issue with xorg 6.8.0. Has there been any progress on this issue?
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
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.
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
This seems similar to bug 5953
Do you still have this issue with recent Xorg & ddx driver ?
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.
*** Bug 18615 has been marked as a duplicate of this bug. ***
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.
Created attachment 35275 [details] xrandr output
Created attachment 35276 [details] xdpyinfo output
Is this still an issue with recent deliverables (xorg-server-1.11.x, recent drivers, etc)?
-- 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.