xserver: Branch 'master'

[Keith Packard]

 randr/rrscreen.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

New commits:
diff-tree 0dc2bb6101704d0fd25f36e2c3df79687f119f5b (from 07630d897ef37cad8b79d073d9edc891d5a7bddd)
Author: Marius Gedminas <mgedmin at b4net.lt>
Date:   Fri Aug 31 21:36:37 2007 -0700

    [RANDR] Compare only milliseconds of config time. (Bug #6502)
    
    The timestamp transferred in the X protocol is a 32-bit number of
    milliseconds.
    
    The timestamp stored in the server is a structure that contains two fields:
    months (!) and milliseconds.
    
    When the server passes the config timestamp to the client, it discards the
    months part and sends only the milliseconds part.
    
    When the server receives the config timestamp from the client, it tries to
    guess the "months" part by looking at the current time and then maybe adding
    or
    subtracting one.  The guess is wrong after the server has been running long
    enough (several hours).
    
    I have added two ErrorF calls around the 'if' statement that returns
    RRSetConfigInvalidConfigTimestamp in randr/randr.c and my Xorg.0.log has
    this:
    
      randr request got good config time: 0:-2103495671
    
    for the first few successful xrandr calls, and
    
      randr request failed with RRSetConfigInvalidConfigTime: client passed
      1:-2103495671, server has 0:-2103495671
    
    when it fails.  The server has been running for 8 and a half hours.
    
    The obvious fix would be to ignore the months field and only compare the
    milliseconds.

diff --git a/randr/rrscreen.c b/randr/rrscreen.c
index 8798b42..811a557 100644
--- a/randr/rrscreen.c
+++ b/randr/rrscreen.c
@@ -766,7 +766,6 @@ ProcRRSetScreenConfig (ClientPtr client)
     pScrPriv = rrGetScrPriv(pScreen);
     
     time = ClientTimeToServerTime(stuff->timestamp);
-    configTime = ClientTimeToServerTime(stuff->configTimestamp);
     
     if (!pScrPriv)
     {
@@ -788,11 +787,15 @@ ProcRRSetScreenConfig (ClientPtr client)
     crtc = output->crtc;
 
     /*
-     * if the client's config timestamp is not the same as the last config
+     * 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
+     * can't even be validated.
+     *
+     * Note that the client only knows about the milliseconds part of the
+     * timestamp, so using CompareTimeStamps here would cause randr to suddenly
+     * stop working after several hours have passed (freedesktop bug #6502).
      */
-    if (CompareTimeStamps (configTime, pScrPriv->lastConfigTime) != 0)
+    if (stuff->configTimestamp != pScrPriv->lastConfigTime.milliseconds)
     {
 	rep.status = RRSetConfigInvalidConfigTime;
 	goto sendReply;