| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Conflicts:
src/i830_display.c
|
|
|
|
|
|
|
|
I830 contained six parallel arrays for pipe-specific data; these
have been moved to a I830PipeRec structure instead.
I830 also contained several unused members:
unsigned int bios_version;
Bool newPipeSwitch;
Bool fakeSwitch;
int fixedPipe;
These have been removed, along with the code that set them.
|
|
|
|
|
|
The panel fitter appears to exist on the 965 hardware (at least) and
causes troubles with DVI output over SDVO when enabled. This patch
checks to see if the panel fitter is pointing at the pipe being configured
and disables it unconditionally in that case. The LVDS driver will configure
it correctly if necessary afterwards.
|
|
|
|
|
|
I've gone back to compare our behavior to it several times, so I'll just keep
the code in tree for now.
|
|
|
|
|
|
|
|
|
|
|
|
This gets the SDVO and CRT outputs I have to have at least 1 common mode
according to RandR.
|
|
|
|
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.
|
|
|
|
|
|
Also, fix some struct padding so that the right bits are sent out.
|
|
|
|
This info hardly useful now that we don't use the BIOS for mode setting.
|
|
|
|
|
|
This should fix display at resolutions/refresh rates in a different multiplier
class than the console display (generally, high resolution modes).
|
|
|
|
|
|
|
|
Some code are duplicated with the new libdrm.
Once this code has been released with xserver,
it can be removed.
See the man page for new options and backwards
3D driver compatibility.
|
|
Now, the generic invariant state is always set while the X Server is active,
and happens automatically when the X Server grabs the DRI lock. More 3D state
is moved to the generic code.
Then, the 3D consumers (video, rotation, render) set last_3d to their enum
entry, and can update their own invariant state when another consumer was
active.
|
|
|
|
|
|
|
|
The calculation no longer made sense, as we don't use the BIOS for mode
selection.
|
|
This used to be called when switching back in to X. It might make some sense
to detect monitors at this time (it happens to occur at resume time, when
monitors are likely to have changed), but it should probably live in either
userland policy with RandR 1.2 or RandR 1.2 XFree86-DDX generic code.
|
|
|
|
The main change is to send SDVO commands using data passed into the send
command function, and receive responses into memory passed into the read
response function, rather than stuff things in/out through dev_priv->sdvo_regs.
This lets us use structures to represent some arguments, which results in a
nice cleanup (and 100% fewer arguments named magicN as a side effect).
Also, the mode set path is changed to not do any preferred input timing
work. We weren't doing anything legitimate with the results, since we didn't
modify the CRTC timing appropriately, so now we just stuff the CRTC timing into
both and hope for the best. This should probably be revisited later.
|
|
|
|
All the SDVO code should now be in lower case rather than StudlyCaps.
This also adjusts the I2C setup to create a bus per SDVO output we set up.
The previous setup with shared buses was failing in some circumstances, which
is probably due to the lack of refcounting in xf86i2c.c.
|
|
|
|
|
