Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

From: Daniel Stone <daniel@fooishbar.org>
To: Rob Clark <robdclark@gmail.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>,
	Ben Widawsky <ben@bwidawsk.net>,
	Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2
Date: Thu, 12 Jan 2017 17:04:46 +0000	[thread overview]
Message-ID: <CAPj87rPtaTgY_xCtvieq9xdOFd38bCwAGZqAVAskh4nqkWqR3Q@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGuxCzOrtz=kZ6K0mJWEfxPaeELA4V=S5LBstAKKHciAnw@mail.gmail.com>

Hi,

On 12 January 2017 at 14:56, Rob Clark <robdclark@gmail.com> wrote:
> On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>> Isn't an implicit offset enough? As in first mask for a specific
>> modifier is for format indexes 0-63, second mask for the same modifier
>> is for 64-127, and so on.
>
> hmm, hadn't thought of that approach.  Definitely if we go w/ implicit
> then we want to have userspace support from the get-go.  For explicit,
> I guess userspace could complain and ignore if it saw a non-zero
> offset similar to what we do w/ pad and unknown flags in the other
> direction?

Implicit is clever but horrible. AFAICT, the only way to do it
properly would be to have a nested forwards loop walk when you first
hit a modifier, searching for further occurrences of that modifier to
collect the complete set of formats that modifier applies to.
Depending on what you did with the structures, you'd either have to
destroy the drm_format_modifiers in the GetPlane return so further
instances of your outer loop didn't hit them, or have a _second_
nested loop walk into wherever you copied the formats/modifiers,
searching for anything with that.

Too clever by half, and everyone will get it wrong. Just add an explicit offset.

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel