| Age | Commit message (Collapse) | Author |
|---|
|
o Check for RANDR_GET_CRTC_INTERFACE before defining functions that
are used only if it is defined.
o Declare a variable before code, and rename it from ret to xvmc_status
to better describe it.
o if 0 some static functions not used.
o Don't declare some unused variables.
o Declare as static some functions that are used only in the file defining it.
o Add a default/fallback return True to the Bool function
src/xvmc/intel_batchbuffer.c:intelInitBatchBuffer().
o Ansify src/xvmc/xf86dri.c.
o Add missing prototype to src/xvmc/xf86dri.h and follow pattern of other
headers by adding "extern" before function prototype.
|
|
Using the new interface allows the server to avoid some flicker at startup.
|
|
Several uses are actually left, which are determined by the X Server
interfaces we're implementing.
|
|
Some machines want DVOA, some DVOB. We can use this quirk to differentiate
them until we come up with a better solution. Patch from Hong Liu.
Fixes #13722.
|
|
We use the wrong DVO output register for ivch which is used for DVO LVDS.
Vbios enables DVOB and driver never touches it, so everything seems
working correctly now.
|
|
It may be that the LVDS chips need to be DVOA and GPIOB only on mobility
devices with them, and DVOC/GPIOE on non-mobility like this 845. But until
more examples are found, just make this one device probe.
|
|
On hardware containing one of these chips (generally single pipe with an LVDS
connected), it's probably better to try to enable it and fail in some cases
than to not probe the output at all.
|
|
Make sure there is some border area to use by changing how the pipe is
configured, then pick a scanline in the middle of the border for load
detection. This lets the load detect code use an active pipe instead of
requiring an idle one.
|
|
|
|
This also results in removal of the setup hook, which was being called
unconditionally and breaking non-ivch dvo drivers.
|
|
|
|
Move clone/crtc config into each output where it's easier to understand (no
need for a switch statement in I830PrepareOutputs. Also, split DVO into
three sub-types (TMDS, LVDS, TVOUT) as those have different cloning
abilities.
|
|
The DVO module interface reflected most of the xf86Output API to the
underlying functions; finish that work given the changes that have since
occurred in the xf86Output API.
Move the LVDS-specific code into the IVCH module and make that work on the
Thinkpad X30 (an i830-based laptop). Panel scaling does not work yet.
|
|
The fixed panel timing will only be available when the LVDS is already on
at X startup.
So far, our only mostly-working LVDS driver is for the i830, and on i830 the
LVDS is always on DVOA, so use that for all LVDS chips. This may need to
change if we support the ch7017 I've seen used on embedded i845, for example.
|
|
|
|
The ihch DVO uses a modified I2C addressing scheme as described
in section 5.2 of the data sheet. Implement this by over-riding
the I2C read and write word routines.
|
|
|
|
|
|
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.
|
