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

[Michel Dänzer]

On Die, 2013-04-30 at 10:31 -0400, Ilija Hadzic wrote: 
> 
> 
> 
> On Tue, Apr 30, 2013 at 5:16 AM, Michel Dänzer <michel at daenzer.net>
> wrote:
>         On Son, 2013-04-28 at 16:07 -0400, Ilija Hadzic wrote:
>         >
>         > No new functionality is needed from X-server or any other
>         library
>         > except one #define in libdrm which should go into libdrm
>         anyway
>         > (it was sent to dri-devel list but has not been merged yet
>         [4]).
>         
>         
>         That change needs
>         
>         #ifndef DRM_CAP_TIMESTAMP_MONOTONIC
>         #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
>         #endif
>         
>         or a dependency on a released version of libdrm with the
>         definition. 
>         
>         
>         
> 
> 
> Yes, I am aware of that. My plan is to get DDX patches reviewed here
> and, if they
> make sense, send a ping to dri-devel list to ask someone with
> push-privileges for libdrm to apply
> Imre Deak's patch before I send v2 series of these patches.  The v2
> series will address
> any comments I receive here along with a libdrm dependency-bump-up
> patch.
> 
> 
> Defining the constant that is really supposed to come from libdrm in
> DDX should
> 
> only be the plan B (e.g., if libdrm push never happens).

Well, in addition to landing the libdrm patch, you'll need to make or
wait for a libdrm release and bump the required version in
xf86-video-ati configure.ac. Seems like a lot of churn for a simple
definition which is effectively set in stone anyway.

As far as I'm concerned, this and the incorrect comment are the only
blockers for this series.


>         > The end result is that regardless in which state the display
>         is, the
>         > application sees the events (time and sequence numbers) that
>         progress
>         > as if the CRTC is running and the events happen at right
>         time points
>         > on the grid determined by the vlbanks (real or
>         interpolated).
>         
>         
>         Indeed, looks like DPMS off no longer has any effect on piglit
>         results. :) Thanks for working on this.
>         
> 
> 
> Forgive me if this question is going to make me look dumb, but given
> that piglit is a rendering test suite, the behavior you are seeing is
> expected. In other words, you are not implying that something is
> wrong, are you?

Indeed, I'm not. piglit has a few GLX tests, some of which could
previously fail when the monitor was in DPMS off state. Your series
fixes that. 

-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer