Checking timestamps in post 1.1 randr requests was never a good idea, let's ignore them and just make the configuration changes.
Signed-off-by: Keith Packard <[email protected]> --- Because the new randr code uses persistent resource ids for all of the objects in question, there's no concern that the configuration will do something weird if done with stale information. As such, we really don't need to check these timestamps, they serve only to cause random failures when applications get them wrong somehow. randr/rrcrtc.c | 33 --------------------------------- 1 files changed, 0 insertions(+), 33 deletions(-) diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c index f5fe765..14f6e45 100644 --- a/randr/rrcrtc.c +++ b/randr/rrcrtc.c @@ -863,19 +863,6 @@ ProcRRSetCrtcConfig (ClientPtr client) goto sendReply; } -#if 0 - /* - * if the client's config timestamp is not the same as the last config - * timestamp, then the config information isn't up-to-date and - * can't even be validated - */ - if (CompareTimeStamps (configTime, pScrPriv->lastConfigTime) != 0) - { - rep.status = RRSetConfigInvalidConfigTime; - goto sendReply; - } -#endif - /* * Validate requested rotation */ @@ -948,16 +935,6 @@ ProcRRSetCrtcConfig (ClientPtr client) #endif } - /* - * Make sure the requested set-time is not older than - * the last set-time - */ - if (CompareTimeStamps (time, pScrPriv->lastSetTime) < 0) - { - rep.status = RRSetConfigInvalidTime; - goto sendReply; - } - if (!RRCrtcSet (crtc, mode, stuff->x, stuff->y, rotation, numOutputs, outputs)) { @@ -1088,16 +1065,6 @@ ProcRRSetPanning (ClientPtr client) time = ClientTimeToServerTime(stuff->timestamp); - /* - * Make sure the requested set-time is not older than - * the last set-time - */ - if (CompareTimeStamps (time, pScrPriv->lastSetTime) < 0) - { - rep.status = RRSetConfigInvalidTime; - goto sendReply; - } - if (!pScrPriv->rrGetPanning) return RRErrorBase + BadRRCrtc; -- 1.7.1 -- [email protected]
pgpVVgLI25BnN.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
