summaryrefslogtreecommitdiff
path: root/randr
diff options
context:
space:
mode:
authorMarius Gedminas <mgedmin@b4net.lt>2007-08-31 21:36:37 -0700
committerKeith Packard <keithp@koto.keithp.com>2007-08-31 21:36:37 -0700
commit0dc2bb6101704d0fd25f36e2c3df79687f119f5b (patch)
tree835a6e93605632fa31ea74ecc18cd9f756cc63c5 /randr
parent07630d897ef37cad8b79d073d9edc891d5a7bddd (diff)
[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.
Diffstat (limited to 'randr')
-rw-r--r--randr/rrscreen.c11
1 files changed, 7 insertions, 4 deletions
diff --git a/randr/rrscreen.c b/randr/rrscreen.c
index 8798b4244..811a5571b 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;