re-probing DDC/EDID
perryh at pluto.rain.com
perryh at pluto.rain.com
Tue May 26 09:11:25 UTC 2009
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.
* 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.
More information about the freebsd-x11
mailing list