I was having consistent system lockups when the vga restore
was first. Moving it to the end has reduced them to an infrequent
occurrence (but, alas, it has happened once since). This does not
make me happy.
DOUBLE_WIDE mode is needed when the pixel clock is > 90% of the core
clock rate. The code guesses what the core clock rate is based on
the bus (AGP -> 133MHz, PCI-E -> 200MHz).
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).
We should use card_fmt for src/mask picture, and use dest color
buffer format helper. Also fix wrong name for G965 texture formats,
and pict_x1r5g5b5 isn't supported by sampler engine.
RandR structures must be re-created when the server reinitializes,
but the driver PreInit function is not re-invoked. Recreate them
manually in this case during ScreenInit.
High pixel clock modes on pipe A of an 8xx chip require
DOUBLE_WIDE mode. It's supposed to be modes > 180MHz or so,
but the board I have requires DOUBLE_WIDE mode for clocks > 108MHz
or so. The limit is related to the core clock speed of the chip, which
can be found indirectly through PCI config space. None of the possible
values explain why this board needs this mode for these relatively low
clock rates though.
Also, create tables of data for the PLL computation and use them
instead of code. I think it's cleaner looking. It is also untested on
9xx. It'll work. Really.
Yes, this means not detecting TV hotplug when two outputs are
already running. An alternative would be to turn off one of the other
outputs temporarily, but that would cause flashing. Something to consider.
Some output detection requires a crtc for load detection, perform all of the
output detection before allocating any crtcs so that there will be a free
crtc for any load detection. Avoids losing TV detection when two monitors
are connected.
While the register is laid out suggesting that you can read a low value while
driving the output high, and the I2C spec seems to indicate that you should be
able to as well, and on some hardware this works successfully, on the i865 and
perhaps some other chips it doesn't. So, if we're not holding the clock or
data pin low during GetBits, tristate the pin so that we can successfully read.
This fixes i865 analog (VGA) DDC so it successfully sees slave acks.
Also, improve the I2C bit-banging debugging.