| 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.
|
|
Since we return early in the CRTC DPMS code, keeping the pipes & clocks
enabled, this code is no longer necessary. As an added bonus, VGA connections
should be reported correctly even when the pipe A quirk is active.
Updates fix for fdo bz #11432.
|
|
On some platforms, the firmware may read & write GPU registers on lid close,
suspend/resume time or during various SMM events. If one of the graphics pipes
is disabled at that time, the GPU may hang due to the programming dependencies
of the various registers.
This patch adds a quirk to force the driver to keep pipe A enabled if
necessary, through user configuration in xorg.conf or via a platform specific
quirk. Leaving the pipe enabled comes at a power cost however, so the quirk
should only be enabled when strictly necessary.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=11432.
|
|
Patch from Hong Liu.
Fixup CRT detection by making sure the pipe is enabled before CRT
detection actually occurs. Fixes bugs Hong was seeing on G35 and other
machines.
|
|
CRT blanking needn't be adjusted to perform load detection on 9xx chips, and
the 8xx load detection path now adjusts blanking just during load detection.
Adjusting the blanking interval turned out to cause many monitors to fail to
sync.
|
|
If the pipe or output have been set to DPMSOff, then load detection will not
work correctly. Also, share the load detection configuration code between
crt and tv outputs.
|
|
Instead of always adding blanking to mode lines, use the FORCE_BORDER option
on i9xx hardware where it works, and dynamically add a bit of border if
necessary on i8xx hardware to make load detection work. This may cause
flashing when a usable crtc is not otherwise idle when load detection is
requested.
|
|
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.
|
|
Be sure to check G33 chip type in:
- sdvo output
- Y-major tile
- crt detect
- and xaa composite
Sorry for that I should have fixed them very earlier...
|
|
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.
|
|
Chips newer than the i830 can force the border color for the active period
of the screen, allowing the load detection to easily see the right data. In
addition, newer chips appear to have more sensible load detection hardware
which either ignores inactive periods on the screen or performs some
longer-term averaging. The i830 appears to provide unfiltered samples of the
detected load.
For the i830, then, emit a border at the bottom of the screen and, for load
detection, simply turn it purple and wait for the current line to be within
the border. Sample an entire scanline, counting the number of times the load
detection sees a monitor. In my testing, the presence of a monitor will
cause the detection to succeed every time, while the absense will cause it
to fail about 75% of the time. The code here, checks for presence at least
75% of the time, which should be adequate.
Also, as the new mode configuration code has already taken care to enable
the CRT output, eliminate much of the load detection code which is simply
duplicating functionality from the general mode setting code. This should
result in faster load detection as this code will now run in no more than
one frame time. It does burn the CPU the whole time though, polling the
displayed scanline register.
|
|
New hooks replace explicit invocation of DPMS functions to manage mode
setting sequencing.
|
|
Start time rotation requires that the pixmap be created after the server has
initialized the screens. Delay the pixmap creation until the first block
handler invocation.
|
|
Yes, there are lots of bits tied together here, and we should split this
patch apart.
Move I830 mode setting to xf86 mode setting.
Make mode setting function also set the base address. This should fix
problems where the base gets set incorrectly at times.
Add driver-independent rotation support, requires driver-specific hooks for
shadow pixmap allocation, otherwise it uses Render for painting.
|
|
Makes the mode setting logic device independent.
Magic rename hooks allow multiple drivers to provide the
generic code without name conflicts.
Rotation code requires special pixmap creation hook, and uses
Render to perform the actual rotation.
|
|
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.
|
|
Add the modelines specified in the per-output monitor and all of the default
modes to the list to each output. Prune the resulting list to specified sync
limits and virtual sizes. Sort the resulting mode list on
preferred/size/refresh.
|
|
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.
|
|
Outputs and Crtcs now have a driver-independent representation which should
permit generic code to control RandR 1.2 and startup configuration.
|
|
This also replaces calls to compat code with the real names of the functions,
and slips #defines to an i830-namespaced version in when doing compat.
The current server version (7.1.99.2) is still left as requiring compat code,
since the version hasn't been bumped yet.
This also fixes some failures to call the compat code, and some failures to
actually compile the compat code. Oops.
|
|
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.
|
|
To share load-detect CRTC allocation with TV driver,
move it to the output driver
|
|
Use i830GeLoadDetectPipe again (instead of missing xf86AllocCrtc). Actually
create new Crtc structures. Fix a few other NULL pointer dereferences.
|
|
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.
|
|
RandR DIX code is preparing for xf86 drivers that want to allocate RandR
objects at PreInit time. This patch adapts to that change without taking
advantage of it.
|
|
Conflicts in PipeSetMode were resolved to use the keithp changes
that pushed more modesetting stuff into the per-pipe function.
Switched availablePipes to num_pipes.
Used modesetting default output configuration.
|
|
ADPA might not have been set right in some cases (DPMS-off monitor, for
example), and a wait for vsync that the bios does was missing.
|
|
operatingDevices and MonType1/MonType2 duplicate information already stored
in the device structures. Eliminate them and replace uses with direct
references to the appropriate other data.
(cherry picked from 3ab7f9693217d8fe993bdc94c376b219b0082961 commit)
|
|
A few more register settings are needed to get CRT output working on the
965 chipset, in particular the the SDVO/UDI clock multiplier register
needed to get set to the default value (3). No, I really don't know what
this does, but it does get the CRT running at a wide range of sizes.
|
|
|
|
operatingDevices and MonType1/MonType2 duplicate information already stored
in the device structures. Eliminate them and replace uses with direct
references to the appropriate other data.
|
|
|
|
|
|
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.
|
|
|
|
|
