On Wed, Oct 26, 2016 at 04:09:00PM +0200, Benjamin Gaignard wrote:
> I have just tested it on my board, no regression :-)
>
> Acked-by: Benjamin Gaignard
>
> 2016-10-25 22:53 GMT+02:00 Sean Paul :
> > On Tue, Oct 25, 2016 at 10:43 AM, Ville Syrjälä
> > wrote:
> >> On Mon, Oct 10, 2016 at 03:1
I have just tested it on my board, no regression :-)
Acked-by: Benjamin Gaignard
2016-10-25 22:53 GMT+02:00 Sean Paul :
> On Tue, Oct 25, 2016 at 10:43 AM, Ville Syrjälä
> wrote:
>> On Mon, Oct 10, 2016 at 03:19:47PM +0300, ville.syrjala at linux.intel.com
>> wrote:
>>> From: Ville Syrjälä
On Mon, Oct 10, 2016 at 03:19:47PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> We don't want all planes to be added to the state whenever a
> plane with fixed zpos gets enabled/disabled. This is true
> especially for eg. cursor planes on i915, as we want cursor
> u
On Tue, Oct 25, 2016 at 10:43 AM, Ville Syrjälä
wrote:
> On Mon, Oct 10, 2016 at 03:19:47PM +0300, ville.syrjala at linux.intel.com
> wrote:
>> From: Ville Syrjälä
>>
>> We don't want all planes to be added to the state whenever a
>> plane with fixed zpos gets enabled/disabled. This is true
On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
> wrote:
> >> I think the
> >> proper way is to keep track of a per-plane zpos changed (or compute
> >> that ad-hoc, we have both states). And only grab more planes if a zpos
> >> valu
On Mon, Oct 10, 2016 at 02:46:35PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 2:19 PM, wrote:
> > From: Ville Syrjälä
> >
> > We don't want all planes to be added to the state whenever a
> > plane with fixed zpos gets enabled/disabled. This is true
> > especially for eg. cursor plan
On Mon, Oct 10, 2016 at 3:32 PM, Ville Syrjälä
wrote:
> On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
>> wrote:
>> >> I think the
>> >> proper way is to keep track of a per-plane zpos changed (or compute
>> >> that ad-hoc, we
From: Ville Syrjälä
We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i91
On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
wrote:
>> I think the
>> proper way is to keep track of a per-plane zpos changed (or compute
>> that ad-hoc, we have both states). And only grab more planes if a zpos
>> value changed.
>
> Doesn't work with normalized zpos. The plane's actual zpos m
On Mon, Oct 10, 2016 at 2:19 PM, wrote:
> From: Ville Syrjälä
>
> We don't want all planes to be added to the state whenever a
> plane with fixed zpos gets enabled/disabled. This is true
> especially for eg. cursor planes on i915, as we want cursor
> updates to go through w/o throttling. Same
10 matches
Mail list logo