[Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

[Daniel Stone]

On 3 May 2017 at 15:07, Liviu Dudau <Liviu.Dudau at arm.com> wrote:
> On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
>> On 3 May 2017 at 11:34, Liviu Dudau <Liviu.Dudau at arm.com> wrote:
>> > You are *really* pushing your luck by not Cc-ing *any* of the maintainers of
>> > the drivers you touch. You do want reviews, don't you?
>>
>> Ouch. I'm very sure Ben does want reviews, but he mainly works in Mesa
>> where you can rely on the list rather than having to CC everyone
>> individually. It was a mistake, so please be more gentle with him;
>> your whole mail comes across as quite hostile to me.
>
> Sorry, I'm not trying to be hostile. Try to read the bolded words with a long
> (southern USA) intonation as if to draw attention to them. You will see that
> it is just pointing to two facts: he does not warn anyone about the changes and
> he is not making the patchset that obviously critical by having a commit message
> that implies everyone should pay attention to it. So he is really hoping to be
> lucky to get reviews (or doesn't actively seek them).

You could achieve the same thing with absolutely no room for
misinterpretation: 'Hi Ben. Not sure if you weren't aware or forgot,
but when posting patches here, please use get_maintainers.pl to build
a CC list. I only really saw this by luck, and other maintainers have
probably missed this too.'

>> It does deserve a much better commit message than what it has, but as
>> he is on holiday for the rest of the week, I can answer. Currently, we
>> advertise which formats each plane is capable of displaying. In order
>> for userspace to be able to allocate tiled/compressed buffers for
>> scanout, we want userspace to be able to discover which modifiers each
>> plane supports as well.
>
> I get the overall goal. We need/want something similar for Mali DP and AFBC buffers.
> What I don't understand is the current aproach (but I've found from Brian that somehow
> I've missed the long discussion(s) around the subject). I was hoping to learn
> from the commit message why he thinks the introduction of this code is the right
> way of doing it. And the IRC logs seem to imply that he is mostly doing something
> that others have agreed upon and he doesn't really care about the approach as long
> as it ticks the "supported by intel driver" box.

Or, with another interpretation, he thinks the various approaches of
doing it are all equally good. He took guidance from a couple of
userspace developers (Weston, ChromeOS), a Freedreno developer and
also I believe an AFBC developer, to end up where he is now, which he
still thinks is fine. In doing so, he's been through several
iterations, always modifying the driver to suit. I think that's a
pretty good way to do development of new uABI, if you ask me. (And
again, I have trouble reading your last sentence as anything other
than hostile.)