On 21/01/15 17:45, Daniel Vetter wrote:
> On Wed, Jan 21, 2015 at 04:59:08PM +, Dave Gordon wrote:
>> On 20/01/15 22:09, Daniel Vetter wrote:
>>> Cursor plane updates have historically been fully async and mutliple
>>> updates batched together for the next vsync. And userspace relies upon
>>> t
On Tue, Jan 20, 2015 at 11:09:14PM +0100, Daniel Vetter wrote:
[...]
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 4d3f3b874dd6..8b626ff3d3bd 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -929,6 +929,7 @@ struct drm_bridge {
> * struct struct d
On Wed, Jan 21, 2015 at 04:59:08PM +, Dave Gordon wrote:
> On 20/01/15 22:09, Daniel Vetter wrote:
> > Cursor plane updates have historically been fully async and mutliple
> > updates batched together for the next vsync. And userspace relies upon
> > that. Since implementing a full queue of asy
On 20/01/15 22:09, Daniel Vetter wrote:
> Cursor plane updates have historically been fully async and mutliple
> updates batched together for the next vsync. And userspace relies upon
> that. Since implementing a full queue of async atomic updates is a bit
> of work lets just recover the cursor spe
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5617
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 353/353
Cursor plane updates have historically been fully async and mutliple
updates batched together for the next vsync. And userspace relies upon
that. Since implementing a full queue of async atomic updates is a bit
of work lets just recover the cursor specific behaviour with a hint
flag and some hacks
