| Age | Commit message (Collapse) | Author |
|---|
|
New hooks replace explicit invocation of DPMS functions to manage mode
setting sequencing.
|
|
intel_output->pI2CBus isn't initialized until the output is all happy and
running, so using it before that is rather unlikely to do much good.
|
|
Move output connection status detection from RandR code up to ProbeModes so
it is done before mode sets are built. Otherwise, the mode building code
will elide all modes the first time through as it ignores outputs that are
disconnected.
Most get_modes functions fetch EDID data; make sure that any
EDID changes are used in the ProbeModes filtering of default modes.
Otherwise, stale EDID data will be used.
Allow outputs to advertise support for interlaced and double scan modes;
prune such modes from the default mode list when outputs do not support them.
|
|
|
|
It is not currently hooked up as it hasn't been tested. The hardware that this
was written for decided to stop working.
|
|
|
|
The documentation states that GPIOB is (generally) used for devices on DVOA
on the motherboard, which appears to be the case on the laptop we have with
LVDS on the motherboard.
This patch is probably not entirely accurate, as there was apparently an LVDS
DVO card sold that could be put in desktop machines, which would likely be on
GPIOE like other ADD cards. Given that we couldn't find one of these cards for
purchase, I'm not worrying about it.
|
|
|
|
The old Init() function is removed and the previous Detect() function is now
init(). This leaves us room in the namespace for a detect() like other
outputs have ("is the monitor connected?"). Also, Power() became dpms(),
taking a DPMSMode*. In general, the mode setting path now matches the intel
internal path, except for the lack of mode_fixup().
|
|
|
|
These names are reasonably short and describe the connector rather than the
target media, but we don't appear to have any way to determine what is on
the other end of the wire. More importantly, they're all unique now.
|
|
Also, fix buffer overflow in i830_debug.c
|
|
To avoid requiring RandR 1.2 in the X server, use the
xf86 Crtc and Output structures as the basis for the default configuration
computation (and, eventually, the config-file based configuration as well).
|
|
It compiles. It definitely doesn't run.
|
|
Place crtc/output in separate structure at head
of driver private structure. Use this from the config code
to make it driver-independent. Still lots of effectively driver
independent code that continues to use driver dependent stuff,
but that will change.
|
|
Outputs and Crtcs are now split between 'generic'
and 'driver specific' pieces in the hope that more code
will be able to migrate to the xf86-generic layer.
Right now, the code remains tangled together, significant
work remains to tease the pieces apart. First the code
needs to be made to actually work as-is though.
|
|
This should let RandR do the right thing in exposing the modes to userland.
As a side effect of getting this working, the SDVO pixel clock range code
was fixed and the mode valid tests for various outputs got extended. Also,
LVDS grew a get_modes for the fixed panel mode.
Note that we now no longer do automatic enabling of outputs at xrandr -s 0,
hotkey, or VT switch. That will be left to generic RandR code later. Also,
generic modes and user-defined modes are once again not validated into the
lists, so this is a regression there.
|
|
The get_modes should return the probed modes only. The driver should then
append to the list (for example, compatible modes listed in other outputs,
or standard VESA modes) to create the list to expose through RandR. That
isn't done yet.
|
|
This will be used by RandR, and should let us clean up some of the initial
display configuration, hopefully.
Also, analog hotplug-based detection is now enabled on G965.
|
|
This is currently disconnected, but will be used in more overhaul work.
This should be where any output limitations, such as clocks, resolution,
scaling limits, or other options, are validated. Other limitations, such as
chipset resolution limits, CRTC clock limits, etc. should be elsewhere.
|
|
This is not a very clean interface, as a number of outputs require tweaks to
the DPLL registers. When possible, the DPLLs are just adjusted in the
per-output post_set_mode, which happens just after the DPLL is enabled.
However, this seems better than the previous method of having all outputs
programmed in the same function.
|
|
Now, the output is only set up if it fully initializes, so it will never exist
if the private it requires doesn't.
|
|
|
|
|
|
|
|
This is a mostly-untested merge of airlied's work. The I2C modules are intended
to be moved into the core server or a separate driver module when they're
functional and we're happy with the API.
|
