Hi,
On 14 December 2016 at 15:21, Pekka Paalanen
wrote:
> On Wed, 14 Dec 2016 14:53:37 + Daniel Stone wrote:
>> On 14 December 2016 at 14:17, Pekka Paalanen
>> wrote:
>> > So, reading both versions of the commit message, I think I was able
>> > reconstruct enough of the idea to see what's g
On Wed, 14 Dec 2016 14:53:37 +
Daniel Stone wrote:
> Hi Pekka,
>
> On 14 December 2016 at 14:17, Pekka Paalanen
> wrote:
> > On Fri, 9 Dec 2016 17:27:13 + Daniel Stone
> > wrote:
> >> However, this is undesirable for DRM. With multi-output, when
> >> assign_planes() is called, any v
Hi Pekka,
On 14 December 2016 at 14:17, Pekka Paalanen
wrote:
> On Fri, 9 Dec 2016 17:27:13 + Daniel Stone wrote:
>> However, this is undesirable for DRM. With multi-output, when
>> assign_planes() is called, any view which wasn't on a plane for our
>> putput was moved to the primary plane,
On Fri, 9 Dec 2016 17:27:13 +
Daniel Stone wrote:
> Hi,
>
> On 9 December 2016 at 16:35, Daniel Stone wrote:
> > However, this is undesirable for DRM. In a multi-output situation,
> > we would see a view only visible on another output, reasonably decide we
> > didn't want it in a plane on o
Hi,
On 9 December 2016 at 16:35, Daniel Stone wrote:
> However, this is undesirable for DRM. In a multi-output situation,
> we would see a view only visible on another output, reasonably decide we
> didn't want it in a plane on our output, and move it to the primary
> plane, causing damage, and a
When we create a new view, assign it to the primary plane from the
beginning.
This made no difference before, since the next surface repaint would
forcibly assign all views to a plane, either through DRM's
assign_planes() hook, or the fallback inside core repaint.
However, this is undesirable for
