SourceValidate is used exclusively by the software cursor code to pull the
cursor off of the screen before using the screen as a source operand. This
eliminates the software cursor from the frame buffer while painting the
rotated image though. Disabling this function by temporarily setting the
screen function pointer to NULL causes the cursor image to be captured.

Setting a mode on an unrotated CRTC was causing all of the rotation updates
to be disabled; the loop looking for active rotation wasn't actually looking
at each crtc, it was looking at the modified crtc many times.

I've managed to solve my own bug (#10545) by applying the following
patch to the xserver.

Please apply.

<Conspiracy mode on>
This monitor is "Vista Certified". I wonder if this is a pure coincidence...
<Conspiracy mode off>

With kind regards
Erik Andrén

Option "Enable" "True" will force the server to enable an output at startup
time, even if the output is not connected. This also causes the default
modes to be added for this output, allowing even sync ranges to be used to
pick out standard modes.

By default, use the screen monitor section for output 0, however, a driver
can change which output gets the screen monitor by calling
xf86OutputUseScreenMonitor.

Was reporting mode size instead of adjusting for rotation.

This Acer monitor reports support for 75hz refresh via EDID, and yet when
that rate is delivered, the monitor does not sync and reports out of range.
Use the existing 60hz quirk for this monitor.

Screen size must reflect rotated mode size when setting rotated mode using
RandR 1.1 SetScreenConfig request.

xf86SetSingleMode tries to resize all crtcs to match the selected mode. When
a CRTC has no matching mode, it now disables the CRTC (instead of crashing).

Also, poke the RandR extension when xf86SetSingleMode is done so that
appropriate events can be delivered, and so that future RandR queries return
correct information.

As the driver EnterVT function generally re-enables the hardware and
prepares it for rendering, it must be called before any gl functions are
called which could touch the hardware.
(cherry picked from commit f24391db)

(cherry picked from commit 645d87cf)

(cherry picked from commit 8c7f56d9)

Erasing this variable causes some outputs (SDVO on intel) to fail
to be correctly reset at server reset time.

This is necessary because server-1.2-branch bumped to 1.1 for xf86CVTMode and
we have xf86XVFillKeyHelperDrawable on top of that.
(cherry picked from commit 788cfce9)

Conflicts:

	hw/xfree86/common/xf86Module.h

Avoid picking up XInput ABI change.

This allows overlay Xv adaptors to work slightly better with compositing
managers.

Bump the video driver ABI minor so drivers only need to check for this at build
time.
(cherry picked from commit a232693c)

Conflicts:

	hw/xfree86/common/xf86Module.h

Avoid picking up XInput ABI version change.

(cherry picked from commit 14d6a9b3)

(cherry picked from commit 27a01e10)

This is a hack, but it should be a NOP for all the setups that worked before
and actually seems to fix some others...

Based on a patch by Peter Teichmann from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338241 .
(cherry picked from commit dc5eb452)

The fbdev API doesn't allow setting the pitch explicitly, so we have to set
the virtual width to the pitch we're using for drawing. This fixes corruption
after changing the virtual width with RandR.
(cherry picked from commit d077c0da)

Fix a TRACE_ENTER typo and only update the internal fbdev mode state cache
after actually setting a mode.
(cherry picked from commit c385bcf0)

The fbdev API allows the driver to 'accept' modes it doesn't really support by
modifying it to the nearest supported mode. Without this check, e.g. vesafb
would appear to accept all modes, even though it actually can't set any modes
other than the bootup mode at all.
(cherry picked from commit f6815cb6)

Yes, two changes in one commit. Sorry 'bout that.

The first change ensures that when pending property values have been
changed, a mode set to the current mode will actually do something, rather
than being identified as a no-op. In addition, the driver no longer needs to
manage the migration of pending to current values, that is handled both
within the xf86 mode setting code (to deal with non-RandR changes) as well
as within the RandR extension itself.

The second change eliminates the two-call Create/AttachScreen stuff that was
done in a failed attempt to create RandR resources before the screen
structures were allocated. Merging these back into the Create function is
cleaner.

desiredX and desiredY were not recorded during xf86InitialConfiguration.
desiredX, desiredY and desiredRotation were not recorded during
xf86SetSingleMode.

Left over from previous version of the code, this memmove will break when
the mode is not Replace.

Pending Properties take effect when the driver says they do, so provide an
API to tell DIX when a property effect is made. Also, allow driver
to reject property values in RRChangeOutputProperty.

Some paths were skipping the event delivery stage.

Erase pointers to structures which are freed at server reset time.

Use xcalloc instead of xalloc when allocating this structure to ensure
consistent contents at startup.

The rotation state is stored in the xf86_config structure which is not
re-initialized at server reset time. Clean it up at CloseScreen time.

This time value makes the bus run slowly enough for even the least reliable
of monitors. Thanks to Pavel Troller for finding the necessary change.

The DDC code sets the I2C timeouts to VESA standards, except that it had an
extra setting of the ByteTimeout value which was wrong (off by a factor of
50). Removing this should help DDC work on many more monitors. Note that the
Intel driver duplicated these settings, along with the error. Yay for cult
and paste coding.

RRModes are referenced by the resource db, RROutput and RRCrtc structures.
Ensure that the mode reference count is decremented each time a reference is
lost from one of these sources. The missing destroys were in
RRCrtcDestroyResource and RROutputDestroyResource, which only happen at
server reset time, so modes would be unavailable in subsequent server
generations.

Rotation block handler was re-registering the rotation damage structure,
creating an infinite loop in the damage code. Track registration of the
damage structure to avoid this.

xf86_reload_cursors is supposed to be called from the crtc mode setting
commit hook; as that happens during server initialization, check for this
case.

This moves most of the cursor management code out of the intel driver and
into the general server code. Of course, the hope is that this code will be
useful for other driver writers as well.

Check out xf86Crtc.h for the usage information, making sure you add the
needed hooks to the crtc funcs structure for your driver.