re-probing DDC/EDID

[Robert Noland]

On Tue, 2009-05-26 at 01:59 -0700, perryh at pluto.rain.com wrote:
> Robert Noland <rnoland at FreeBSD.org> wrote:
> 
> > On Mon, 2009-05-25 at 14:12 -0700, perryh at pluto.rain.com wrote:
> > > Robert Noland <rnoland at FreeBSD.org!rnoland at agora.rdrop.com> 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.

Watch xorg.log while running xrandr -q.  If you have a virtual set large
enough to display the new larger mode then it will show up...

robert.

> * 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.
-- 
Robert Noland <rnoland at FreeBSD.org>
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20090526/3c62326f/attachment.pgp