v2: improved swap/MSC-wait scheduling in DPMS-off state

[Alex Deucher]

On Wed, May 8, 2013 at 10:39 PM, Ilija Hadzic <ilijahadzic at gmail.com> wrote:
> The following patch series is a version 2 of the patches
> sent about two weeks ago [1] with the objective to add full
> emulation of a running CRTC while the display is in DPMS-off
> state. This series addresses the following issues:
>
> 1) Fixed an incorrect comment as pointed by Richard Wilbur.
> 2) Added conditional #define of DRM_CAP_TIMESTAMP_MONOTONIC
>    as requested by Michel Dänzer.
> 3) Fixed two failures of glx-oml-sync-control-waitformsc piglit
>    test (last patch, which is new, and patch #7, which existed before
>    but is now amended) address the issue (see the commit messages
>    for details).
> 4) Changed the way the last known vblank rate is stored (see commit
>    message in patch #5 for details).
> 5) Simplified a few things (see patch #9 for details)
> 6) Amended other patches as needed to reconcile them with
>    the above changes.
>
> There was a third kind of failure in piglit where test
> glx-oml-sync-control-swapbuffersmsc-return was failing with incorrect
> SBC [2]. That problem is outside the scope of this patch series, it existed
> before and cannot be fixed with DDX patches. I tracked it all the way
> up to DRI2SwapEvent function in DIX and just before DIX calls
> WriteEventsToClient (i.e., end of hardware-DDX-DIX path) the SBC is
> still correct. Then I tracked it from the top down and got to
> dri2XcbSwapBuffers in Mesa (everything below that is generic message
> processing code from the server) and SBC is incorrect there. So I think
> we are dealing with some ugly corruption of messages between the X server
> and the application, which I, admittedly, don't fully understand. However,
> what I did proves that it's unrelated to DDX, so it's a topic for a different
> thread on a different mailing list.
>
> Hopefully, this patch series addresses all concerns and problems
> raised so far.

For the series:
Reviewed-by: Alex Deucher <alexander.deucher at amd.com>

>
> thanks,
>
> Ilija
>
> [1] http://lists.x.org/archives/xorg-driver-ati/2013-April/024649.html
> [2] http://lists.x.org/archives/xorg-driver-ati/2013-May/024677.html
>
>
> _______________________________________________
> xorg-driver-ati mailing list
> xorg-driver-ati at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>