| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
