From owner-freebsd-x11@FreeBSD.ORG Tue May 26 09:11:25 2009 Return-Path: Delivered-To: freebsd-x11@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA0D7106564A; Tue, 26 May 2009 09:11:25 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 863808FC22; Tue, 26 May 2009 09:11:25 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n4Q9BPsS064250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 May 2009 02:11:25 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n4Q9BP1m064249; Tue, 26 May 2009 02:11:25 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA08800; Tue, 26 May 09 02:00:42 PDT Date: Tue, 26 May 2009 01:59:58 -0700 From: perryh@pluto.rain.com To: rnoland@FreeBSD.org Message-Id: <4a1baf8e.Lz5OEp/BR3fkQ+QO%perryh@pluto.rain.com> References: <4a164879.9A1SKOjgHUb7X9q6%perryh@pluto.rain.com> <1243015185.63754.104.camel@balrog.2hip.net> <4a1724c4.OuQCIyZ462E1cHYx%perryh@pluto.rain.com> <1243089327.63754.1345.camel@balrog.2hip.net> <4a1a288f.Z0ZX9ngtqKNukKbL%perryh@pluto.rain.com> <1243259500.1787.986.camel@balrog.2hip.net> <4a1b09b3.ewnqp2rizVfsYpk5%perryh@pluto.rain.com> <1243293431.1704.387.camel@balrog.2hip.net> In-Reply-To: <1243293431.1704.387.camel@balrog.2hip.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-x11@FreeBSD.org Subject: Re: re-probing DDC/EDID X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2009 09:11:25 -0000 Robert Noland wrote: > On Mon, 2009-05-25 at 14:12 -0700, perryh@pluto.rain.com wrote: > > Robert Noland wrote: > > > > > If you look at your xorg log, you should see the modes > > > that are probed and calculated for the display. > > > > Indeed, but only during startup AFAIK. What I am looking for > > is a way to repeat the probing and calculation, _without_ > > restarting X. And yes, I recognize that -- since X is not > > being restarted -- such an operation will not affect what is > > being displayed: it will only produce a report. > > > > The question is, is this possible? > > I am fairly certain that this happens when you do an "xrandr -q" > Have you actually tried any of the things that I've suggested? Yes. You suggested: * Running "xrandr -q". I previously provided the output from having done so, noting that it appeared to be reporting the monitor info pertaining to the older monitor -- thus presumably cached at startup -- rather than anything which might have been produced by rerunning the probe after I had switched to the new monitor. There are at least three resolutions provided by the new monitor which are not in the "xrandr -q" report, and two of them (720x400 and 640x350) are smaller than the old maximum of 1280x1024 and thus presumably should not have been suppressed based on being too large to be usable by the currently-running server. Furthermore, the 342mm x 271mm screen dimensions reported by "xrandr -q" are those of the old monitor; the new one is about 517mm x 324mm. * Finding out which display driver is being used. I replied that, based on the xorg.conf produced by -configure, it appeared to be ATI. (If there is a better way to find out, I don't know about it.) * Removing the modelines from xorg.conf. I have not tried that, but I have observed that "xrandr -q" does not seem to cause xorg.conf to be reread, unless it is somehow able to do it without updating any of the inode's three timestamps. (I'd expect it to update the access time, or perhaps the inode-change time instead if it were going to the trouble of explicitly setting the access time to its prior value.) Thus I don't suppose that any change to xorg.conf would become effective until a restart of X. * Looking in the xorg log file, after running "xrandr -q", for a new probe report. "xrandr -q" does not seem to have appended anything to the xorg log file, nor does its manpage indicate that it should.