Hi,
On 11 July 2015 at 02:05, Bryce Harrington wrote:
> On Fri, Jun 26, 2015 at 02:16:55PM -0500, Derek Foreman wrote:
>> On 22/06/15 11:25 AM, Daniel Stone wrote:
>> > Hi,
>> > Thanks to everyone who reviewed the previous series. This new series
>> > cleans up the previous patches, introduces a
On Fri, 10 Jul 2015 18:05:48 -0700
Bryce Harrington wrote:
> On Fri, Jun 26, 2015 at 02:16:55PM -0500, Derek Foreman wrote:
> > On 22/06/15 11:25 AM, Daniel Stone wrote:
> > > Hi,
> > > Thanks to everyone who reviewed the previous series. This new series
> > > cleans up the previous patches, intr
On Fri, Jun 26, 2015 at 02:16:55PM -0500, Derek Foreman wrote:
> On 22/06/15 11:25 AM, Daniel Stone wrote:
> > Hi,
> > Thanks to everyone who reviewed the previous series. This new series
> > cleans up the previous patches, introduces a few fixes (e.g. not relying
> > on a repaint to pull us out of
Hi,
On 29 June 2015 at 07:53, Pekka Paalanen wrote:
> On Fri, 26 Jun 2015 14:27:48 +0100
> Daniel Stone wrote:
>> On 24 June 2015 at 13:11, Pekka Paalanen wrote:
>> > I think the best way to cache state is to let it stay in the kernel,
>> > and avoid submitting a disable followed by the old sta
On Fri, 26 Jun 2015 14:27:48 +0100
Daniel Stone wrote:
> Hi,
>
> On 24 June 2015 at 13:11, Pekka Paalanen wrote:
> > I think the best way to cache state is to let it stay in the kernel,
> > and avoid submitting a disable followed by the old state that's already
> > there. If we manage that, ma
On 22/06/15 11:25 AM, Daniel Stone wrote:
> Hi,
> Thanks to everyone who reviewed the previous series. This new series
> cleans up the previous patches, introduces a few fixes (e.g. not relying
> on a repaint to pull us out of DPMS), and crucially adds support for the
> libdrm TEST_ONLY interface (
Hi,
On 24 June 2015 at 13:11, Pekka Paalanen wrote:
> On Wed, 24 Jun 2015 12:22:15 +0100
> Daniel Stone wrote:
>> On 23 June 2015 at 13:28, Pekka Paalanen wrote:
>> > On Tue, 23 Jun 2015 11:48:56 +0100
>> > Daniel Stone wrote:
>> >> > So, the DRM planes we have not assigned yet but were enable
Hello
On Wed, 24 Jun 2015 12:22:15 +0100
Daniel Stone wrote:
> Hi,
>
> On 23 June 2015 at 13:28, Pekka Paalanen wrote:
> > On Tue, 23 Jun 2015 11:48:56 +0100
> > Daniel Stone wrote:
> >> > So, the DRM planes we have not assigned yet but were enabled, shouldn't
> >> > they be disabled in the
Hi,
On 23 June 2015 at 13:28, Pekka Paalanen wrote:
> On Tue, 23 Jun 2015 11:48:56 +0100
> Daniel Stone wrote:
>> This is the reason for the large 'XXX' comment when calling
>> populate_atomic_plane inside repaint_atomic. So far, my thought has
>> been to add yet another parameter (ugh) to popul
On Tue, Jun 23, 2015 at 12:48 PM, Daniel Stone wrote:
>> This is assuming we cannot do without the primary plane. If it was
>> possible to drive truely universal planes, we would not know if we need
>> a primary plane until we know if there is anything on it. You'd have to
>> first assume the prim
On Tue, 23 Jun 2015 11:48:56 +0100
Daniel Stone wrote:
> Hi,
>
> On 23 June 2015 at 11:26, Pekka Paalanen wrote:
> > you asked me to take a look at the assing_planes code wrt. TEST_ONLY
> > and backtracking.
>
> Thanks!
>
> As a general comment, carried over from IRC: I think we should get
>
Hi,
On 23 June 2015 at 11:26, Pekka Paalanen wrote:
> you asked me to take a look at the assing_planes code wrt. TEST_ONLY
> and backtracking.
Thanks!
As a general comment, carried over from IRC: I think we should get
Mario's series reviewed and merged first. It looks like good work, and
I don'
On Mon, 22 Jun 2015 17:25:05 +0100
Daniel Stone wrote:
> Hi,
> Thanks to everyone who reviewed the previous series. This new series
> cleans up the previous patches, introduces a few fixes (e.g. not relying
> on a repaint to pull us out of DPMS), and crucially adds support for the
> libdrm TEST_O
Hi,
Thanks to everyone who reviewed the previous series. This new series
cleans up the previous patches, introduces a few fixes (e.g. not relying
on a repaint to pull us out of DPMS), and crucially adds support for the
libdrm TEST_ONLY interface (allowing us to check before we commit, e.g.
that a p
14 matches
Mail list logo
