frederik
/
xserver
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[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.
This commit is contained in:
Marius Gedminas 2007-08-31 21:36:37 -07:00 committed by Keith Packard
parent 07630d897e
commit 0dc2bb6101
1 changed files with 7 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
randr/rrscreen.c
View File

@ -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;