New monitor, pink vertical line and crazy screen resolution with Evergreen + KMS
Dave Witbrodt
dawitbro at sbcglobal.net
Tue Mar 2 17:06:07 PST 2010
James Cloos wrote:
>>>>>> "Dave" == Dave Witbrodt <dawitbro at sbcglobal.net> writes:
>
> Dave> 2) Monitor OSD info still reports 1922x1200, a seemingly impossible video mode!
>
> Do any of the lines in the log mention 1922?
I believe you are referring to Xorg.0.log here? If so, DRM + KMS has
already set the mode by the time the X server runs. X itself queries
the monitor, which reports 1920x1200 (among others) as an available mode.
If you are are referring to 'dmesg' output, the only mode info I ever
see printed there is the FB console setting 240x75 text mode.
In short:
1) Once radeondrmfb kicks in (before X server runs), the monitor's
onscreen display (using control panel buttons) indicates a bizarre
1922x1200 display mode. (Shouldn't the monitor reject that as out of
range?)
2) X server only indicates (in Xorg.0.log and via 'xrandr -q') that the
mode is 1920x1200.
KMS is miscommunicating with the monitor when using HDMI (or
DVI-to-HDMI), setting up a funky 1922x1200 mode. DRM believes it has
set up 1920x1200, so is probably reporting that to X. X reports
1920x1200, both as a mode detected as supported by the monitor and as
the mode it is selecting.
> I'm curious whether the modeline is being mis-calculated due to a
> visible vs blanking period vs porch vs sync issue, or pixel freq
> or hfreq rounding issue, or something else of that sort?
Yeah, it reminds of the way CRT displays could be programmed to set up
nonstandard modes, including stuff that would damage the monitor. I
always assumed that LCD displays did not allow nonstandard/unsupported
modes to be programmed, but at the moment it seems clear that they do.
(Or this one does.) The pink (or light purple) vertical line appears to
be 2 pixels wide, apparently corresponding to the extra 2 pixels in the
strange 1922 mode reported by the monitor.
Is there a way to get KMS to output graphics resolution info during the
boot sequence? Something like a "debug=1" kernel parameter?
Thanks,
Dave W.
More information about the xorg-driver-ati
mailing list