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.
Add lots of register debugging to track delta from BIOS settings.
Fix various mode settings to mirror BIOS sDVO values.
Disable analog/lvds output on pipe with sDVO.
Borrow Dave Airlie's I830xf86ValidateDDCModes code.
Fix various sDVO I2C messages to mirror Dave's code.
Also, pend bound computations to register writes to allow
updates to individual values that are 'out of spec' so
the client can update multiple values.
(cherry picked from 190f9ad060 commit)
Also, pend bound computations to register writes to allow
updates to individual values that are 'out of spec' so
the client can update multiple values.
Eric Anholt
Keith Packard
Keith Packard
Lukáš Hejtmanek
Dave Airlie
Matthieu Herrb