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

[Liviu Dudau]

On Wed, May 03, 2017 at 03:14:56PM +0100, Daniel Stone wrote:
> 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.'

Agree, probably a better tone. Apologies to Ben for the initial form. I'm sure
he will do the correct thing next time.

> 
> >> 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.)

I am getting the message. You think I am too strong here, so I'm going to back off.
Also look forward to see the next version where he takes into account the technical
comments that I have sent.

Best regards,
Liviu

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯