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.
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.
This patch tracks the protocol changes which introduce more complex
semantics for RandR output properties including pending and valid value
information.
Add function to keep pointer within valid crtc areas.
Finish event delivery and swapping code.
Separate configuration from layout changes to send correct events.
Provide a Xinerama implementation when DIX version isn't enabled. This
version exposes each crtc as a separate 'screen' and reports the size of
that patch. The extension also sends ConfigureNotify events to the root
window whenever crtcs change so that applications will re-fetch xinerama
information. This actually works for metacity.
