Bug 21987 - RANDR timestamps are not updated correctly
Summary: RANDR timestamps are not updated correctly
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-28 13:38 UTC by Federico Mena-Quintero
Modified: 2009-07-12 02:41 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
0001-Add-missing-fields-to-SRR-NotifyEvent.patch (2.02 KB, patch)
2009-05-29 12:59 UTC, Federico Mena-Quintero
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Federico Mena-Quintero 2009-05-28 13:38:56 UTC
* First bug:

I have two monitors plugged in.  I call XRRGetScreenResources().  The reply comes with configTimestamp A.

Then I unplug a monitor.  I call XRRGetScreenResources() again, to make the server refresh its view of the available outputs.  The reply comes with configTimestamp B.  As expected, B > A.

However, I also get an RRScreenChangeNotify event, but its config_timestamp is C, and C < A.  Actually, C is way smaller than A --- it sounds like it's just the time at which my X server started.

The config_timestamp from the event should match the configTimestamp from the reply of the call to XRRGetScreenResources() that caused the event.

* Second bug:

The following RANDR requests take a "timestamp" argument.  The server is supposed to check if that timestamp is not earlier than the last-set timestamp.

RRSetScreenConfig
RRSetCrtcConfig
RRSetPanning

When I do one of those requests, I get an RRScreenChangeNotify event.  However, its timestamp never changes (that's the "last-set time"), even though I clearly made a change in the configuration.

The timestamp of the event should match the timestamp which I specified when executing those requests.  That way I can use the timestamp to distinguish "oh, I got this RANDR event because hotplug happened" from "oh, I got this RANDR event because I made a change to the configuration myself".

Also, the reply that comes from a subsequent XRRGetScreenResources() does not come with an updated timestamp (the last-set one).  It has the same value as before.

* Third bug:

In all the RANDR events that I ever get, "serial" is always unchanged.  It's just some random number, but it is always the same.
Comment 1 Keith Packard 2009-05-28 14:48:22 UTC
commit b810ce5a7608cb243d0bc452fb7e0d18683e699a
Author: Keith Packard <keithp@keithp.com>
Date:   Thu May 28 14:43:27 2009 -0700

    Make RANDR 'set' timestamps follow client specified time. Bug 21987.
    
    The lastSetTime value which indicates when the configuration within the
    server was last changed was not getting set in the appropriate RandR
    requests.
    
    Signed-off-by: Keith Packard <keithp@keithp.com>

diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 7b724ae..716cb30 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -990,6 +990,7 @@ ProcRRSetCrtcConfig (ClientPtr client)
        goto sendReply;
     }
     rep.status = RRSetConfigSuccess;
+    pScrPriv->lastSetTime = time;
     
 sendReply:
     if (outputs)
@@ -999,7 +1000,7 @@ sendReply:
     /* rep.status has already been filled in */
     rep.length = 0;
     rep.sequenceNumber = client->sequence;
-    rep.newTimestamp = pScrPriv->lastConfigTime.milliseconds;
+    rep.newTimestamp = pScrPriv->lastSetTime.milliseconds;
 
     if (client->swapped) 
     {
@@ -1149,6 +1150,8 @@ ProcRRSetPanning (ClientPtr client)
     if (! pScrPriv->rrSetPanning (pScreen, crtc, &total, &tracking, border))
        return BadMatch;
 
+    pScrPriv->lastSetTime = time;
+
     rep.status = RRSetConfigSuccess;
 
 sendReply:
diff --git a/randr/rrscreen.c b/randr/rrscreen.c
index 94bf3ce..a7533c9 100644
--- a/randr/rrscreen.c
+++ b/randr/rrscreen.c
@@ -945,8 +945,10 @@ ProcRRSetScreenConfig (ClientPtr client)
 
     if (!RRCrtcSet (crtc, mode, 0, 0, stuff->rotation, 1, &output))
        rep.status = RRSetConfigFailed;
-    else
+    else {
+       pScrPriv->lastSetTime = time;
        rep.status = RRSetConfigSuccess;
+    }
 
     /*
      * XXX Configure other crtcs to mirror as much as possible
Comment 2 Federico Mena-Quintero 2009-05-29 12:59:42 UTC
Created attachment 26298 [details] [review]
0001-Add-missing-fields-to-SRR-NotifyEvent.patch

I found a couple of places where the "swap this event" functions were missing some fields.  This patch fixes that.
Comment 3 Federico Mena-Quintero 2009-05-29 17:27:42 UTC
I turns out that my "first bug" and "third bug" were false alarms, sorry!  I had an uninitialized variable in my code to print the timestamps.

Keith's patch fixes the timestamps for me, and my patch is to fix the byte swapping functions.
Comment 4 Federico Mena-Quintero 2009-05-29 21:25:02 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=345551 for other weirdness with event fields.
Comment 5 Julien Cristau 2009-05-30 02:17:04 UTC
> --- Comment #4 from Federico Mena-Quintero <federico@ximian.com>  2009-05-29 21:25:02 PST ---
> See https://bugzilla.redhat.com/show_bug.cgi?id=345551 for other weirdness with
> event fields.
> 
Fixed in libXrandr, commits f176b2bda103f6f38aabab8207f47a02cc797659 and
0fa7452220701ee44d8bafc57001e362afcedb0c.
Comment 6 Keith Packard 2009-06-09 13:49:46 UTC
patches applied to master and proposed for a 1.6 point release
Comment 7 Keith Packard 2009-06-09 13:50:09 UTC
missed the commit button
Comment 8 Federico Mena-Quintero 2009-06-10 14:59:41 UTC
Thanks for commiting, Keith :)
Comment 9 Lukasz Kurylo 2009-07-06 03:54:06 UTC
(In reply to comment #6)
> patches applied to master and proposed for a 1.6 point release
> 

Can this patch be related to my latest problems with xrandr commandline tool:
xrandr --output VGA --auto
xrandr: Configure crtc 0 invalid time

Before this patch it was ok. Does xrandr tool needs fixing? It uses "CurrentTime" whatever it is.
Comment 10 Johannes Rudolph 2009-07-12 02:19:13 UTC
Regarding the comment of Lukasz: See the Ubuntu bug report https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/394490 about the issue for additional information. The strange thing is that grandr still works although it uses CurrentTime exactly as xrandr.
Comment 11 Johannes Rudolph 2009-07-12 02:41:03 UTC
(In reply to comment #10)
> Regarding the comment of Lukasz: See the Ubuntu bug report
> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/394490 about the
> issue for additional information. The strange thing is that grandr still works
> although it uses CurrentTime exactly as xrandr.
> 

xrandr 1.3.0 built from source works as expected.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.