This moves us to maintaining MonPtrs per pipe instead of using the EDID
structure "xf86MonPtr", which is closer to what we want to be looking at when
doing validation. The new validation isn't enough yet -- particularly, we
aren't importing and validating the custom modelines to the pipes when
applicable, but this will be easier than (for example) trying to make flat
panel modes pass xf86ValidateModes through various gross hacks.
Hotplug turn-on/off also happens at SwitchMode time now, instead of at randr
probe time.
This is the case on the Mac mini, which is an i945GM but has no LVDS attached.
Powering on with the power timing registers zeroed would probably be a bad idea,
even if there was a panel attached.
- Don't mess with pScrn->monitor->Modes, and instead make our own availModes.
- Don't re-program the pipe with the same values (no flicker at xrandr)
- Move a bunch of stuff that should be exposed through the public API (probably)
to i830_xf86Modes.c
- Use a table with established modes plus GTF to come up with modes from EDID,
instead of trying to walk and find one in pScrn->monitor->Modes. I think
this is correct.
- Reset clone state if we've detected new pipes, which should turn on the
cursor.
Now, DDC modes always end up being preferred to custom modelines, even if
smaller. This should probably be fixed by inserting custom modelines into
the probed mode list if they're valid according to the probed parameters of the
monitor.
Too much code is lifted from static functions in xf86Mode.c, and those should be
made unstatic if possible. Using xf86ValidateModes is also rather hacky, and
I want to break the function down, but this is a first step.
This is the first stage of getting runtime monitor attachment. The old i830
GTF code is returned to use to provide suitable modelines for xf86ValidateModes
in the LVDS case, even though the LVDS doesn't care about the modeline and just
always programs its fixed values.
I had interpreted the docs as saying that the multiplier setting would further
divide the clock and stuff dummy bytes in. Instead, we have to set the DPLL at
the higher clock rate, and the pixel multiplier just controls the stuffing of
dummy bytes. Also, we have to set the multiplier both in the graphics chip and
on the SDVO device on the other side.
This method is slower (~5ms), but works on older chipsets. Also, load-based
detection is disabled, as it can be fooled by other outputs on the pipe being
active, such as LVDS.
New i915 drm ioctl (in version 1.5) allows the X server to select
which pipe drives vblank interrupts. Use this to drive from the 'preferred'
pipe. Yes, per-window vblanks would be nice in a shared fb environment.
Maybe someday.
(cherry picked from 2fb375b665 commit)
New i915 drm ioctl (in version 1.5) allows the X server to select
which pipe drives vblank interrupts. Use this to drive from the 'preferred'
pipe. Yes, per-window vblanks would be nice in a shared fb environment.
Maybe someday.
ones for EXA support when available). Also, add an abstraction of XAA/EXA
MarkSync and WaitSync functionality so we don't need to sprinkle the ifdefs all
over, and correctly use them.
if we're resuming - it's not reliable.
But then, neither is the BIOS, but it's
the best we can hope for until Eric's work
is complete.
Try setting another mode to cater for some
broken BIOS' too.
Eric Anholt
Alan Coopersmith
Alan Hourihane
Matthieu Herrb
Keith Packard
Wang Zhenyu