Using pre-init computed RandR information, make reasonable
default choices for the output configuration at startup time.
Either some preferred size or a size which yields 96dpi is chosen,
from which other monitors are set to a similar size. The largest
size sets the screen size.
This needs to be extended to respect config file settings, but
those have not been defined yet.
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.
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 3ab7f96932 commit)
Also, remove setting of some other random registers that appears to have
been spammed in at the same time, and don't try to disable on the I830, before
this register existed.
DSPASURF/DSPBSURF can only take page aligned values, ignoring
the lower order bits. So, place the offset for the output
within the frame buffer in the DSPABASE/DSPBBASE registers instead.
Letting the ring buffer or other objects be allocated within the lowest
portion of memory appears to trash some memory mapping data; I'm assuming
this is the GATT table on the 965. Just marking this out of bounds for
allocation fixes this problem.
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.
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.
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.
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.
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.
This is the TV connector on board for the 915GM and 945GM.
It is currently not hooked up to output initialization as it's entirely
untested. However, I think this is a reasonable starting point for getting
TV-out actually working.
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.
I was unable to find the native LVDS panel physical size in the BDB
information. I would prefer to report accurate information through RandR if
possible though.
Keith Packard
Eric Anholt
Keith Packard
Alan Hourihane
Wang Zhenyu
Thomas Hellstrom
Michel Dänzer
Adam Jackson
Keith Packard