[PATCH 3/3] DRI2: defer swap if relevant CRTC is in DMPS off state

[Ilija Hadzic]

>>
>> I guess you mean CRTC private.
>
> I mean what I wrote.
>
>> There is no drawable private
>
> So add one.
>

That would require changing structures in the DIX side of the code. I
could add a driver-private structure to DrawableRec and keep the most
of the fix contained to DDX or parts of the fix could be moved to DIX,
where  DRI2DrawableRec (DRI2-private structure of a drawable) already
exists. I hesitated to do this for the sake of a fix that I thought
affected one driver only, but I tested last night with Intel and it
looks like Intel has the same problem (and looking at the Intel DDX
code, it's for the same reason). I didn't test Nouveau, but quick peek
at the code tells me that it will probably have the opposite problem
that would make the application completely block when screen goes off.
The latter was considered a bug in ATI driver (#49761), but it was
probably just never noticed in Nouveau.

Anyway, given that the problem spans beyond one device, I think it now
makes sense to modify the DIX code, but the proposed fix will have to
be discussed with a wider audience. So nevermind the patches for now,
I'll try to cut something that addresses other GPUs as well.

>> and such information would not be per-drawable anyway (it would be per-CRTC).
>
> Eh? The MSC and related values are properties of the drawable, not the
> CRTC (there is no concept of a CRTC in GLX/DRI2 at all). Only tracking
> this per CRTC will break with several clients synchronizing to the same
> CRTC.
>
>

I understand that, but let me try to clarify what I had in mind,
although it may be moot in the light of what I said above. Sure MSC is
maintained per-drawable, but my understanding is (please correct me if
I am missing something) that when a drawable is displayed on a CRTC,
the values it will get for MSC will be the vblank counters that
originate from the CRTC. So if two drawables are on the same CRTC,
their MSCs will be in lock-step. So when the CRTC is disabled (i.e.,
its vblank counters are not progressing) and the user space takes over
the role of producing "emulated" counters, it can do this by
maintaining this emulated count on per-CRTC basis.

Anyway, given that the fix will probably spread to other GPUs and that
it may involve changes to the xserver code, I think I can do this your
way.

-- Ilija