diff options
author | Marius Gedminas <mgedmin@b4net.lt> | 2007-08-31 21:36:37 -0700 |
---|---|---|
committer | Keith Packard <keithp@koto.keithp.com> | 2007-08-31 21:36:37 -0700 |
commit | 0dc2bb6101704d0fd25f36e2c3df79687f119f5b (patch) | |
tree | 835a6e93605632fa31ea74ecc18cd9f756cc63c5 /randr | |
parent | 07630d897ef37cad8b79d073d9edc891d5a7bddd (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.c | 11 |
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; |