On 11/02/2020 17:41, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 04:40:21PM +0100, Daniel Vetter wrote:
>> On Tue, Feb 11, 2020 at 03:00:30PM +0200, Ville Syrjälä wrote:
>>> On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
Hi Ville,
On 10/02/2020 18:03, Ville Syrjäl
On Tue, Feb 11, 2020 at 04:40:21PM +0100, Daniel Vetter wrote:
> On Tue, Feb 11, 2020 at 03:00:30PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> > > Hi Ville,
> > >
> > > On 10/02/2020 18:03, Ville Syrjälä wrote:
> > >
> > > > The usual approac
On Tue, Feb 11, 2020 at 03:00:30PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> > Hi Ville,
> >
> > On 10/02/2020 18:03, Ville Syrjälä wrote:
> >
> > > The usual approach we follow in i915 for things that affect more
> > > than one plane is is to
On Tue, Feb 11, 2020 at 11:11:34AM +0200, Tomi Valkeinen wrote:
> Hi Ville,
>
> On 10/02/2020 18:03, Ville Syrjälä wrote:
>
> > The usual approach we follow in i915 for things that affect more
> > than one plane is is to collect that state into the crtc state.
> > That way we get to remember it f
Hi Ville,
On 10/02/2020 18:03, Ville Syrjälä wrote:
The usual approach we follow in i915 for things that affect more
than one plane is is to collect that state into the crtc state.
That way we get to remember it for the planes that are not part
of the current commit.
And when we have state tha
On Mon, Feb 10, 2020 at 05:44:19PM +0200, Jyri Sarha wrote:
> On 10/02/2020 15:21, Ville Syrjälä wrote:
> > On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
> >> On 07/02/2020 20:45, Ville Syrjälä wrote:
> >>> On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
> On 07/02/20
On 10/02/2020 15:21, Ville Syrjälä wrote:
> On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
>> On 07/02/2020 20:45, Ville Syrjälä wrote:
>>> On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
On 07/02/2020 20:18, Jyri Sarha wrote:
> The old implementation of placing pl
On Sun, Feb 09, 2020 at 02:50:09PM +0200, Jyri Sarha wrote:
> On 07/02/2020 20:45, Ville Syrjälä wrote:
> > On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
> >> On 07/02/2020 20:18, Jyri Sarha wrote:
> >>> The old implementation of placing planes on the CRTC while configuring
> >>> the
On 07/02/2020 20:45, Ville Syrjälä wrote:
> On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
>> On 07/02/2020 20:18, Jyri Sarha wrote:
>>> The old implementation of placing planes on the CRTC while configuring
>>> the planes was naive and relied on the order in which the planes were
>>>
On Fri, Feb 07, 2020 at 08:26:17PM +0200, Jyri Sarha wrote:
> On 07/02/2020 20:18, Jyri Sarha wrote:
> > The old implementation of placing planes on the CRTC while configuring
> > the planes was naive and relied on the order in which the planes were
> > configured, enabled, and disabled. The situat
On 07/02/2020 20:18, Jyri Sarha wrote:
> The old implementation of placing planes on the CRTC while configuring
> the planes was naive and relied on the order in which the planes were
> configured, enabled, and disabled. The situation where a plane's zpos
> was changed on the fly was completely bro
The old implementation of placing planes on the CRTC while configuring
the planes was naive and relied on the order in which the planes were
configured, enabled, and disabled. The situation where a plane's zpos
was changed on the fly was completely broken. The usual symptoms of
this problem was scr
12 matches
Mail list logo
