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

[Ville Syrjälä]

On Thu, Jan 12, 2017 at 05:04:46PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 12 January 2017 at 14:56, Rob Clark <robdclark at gmail.com> wrote:
> > On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
> > <ville.syrjala at 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.

Not sure for what that is the "only way". In fact I can't right now
think of any operation that would require an extra loop necessarily.
For some things you might just want to look for a specific
format+modifier combo, for that it doesn't matter how many blocks there
are. And if you want to transform the reply into some less convoluted
form, well then you'd just need some modifier+dynamic format list thing,
or if you want to keep to bitmasks you'd either need a bitmask that can
grow when running out of bits or just make it big enough to handle a
sufficiently large worst case number of bits.

Dunno, maybe I just lack imagination. Then again, I'm not even sure if
we're talking about userspace of kernel code here, which might explain
my general confusion :)

-- 
Ville Syrjälä
Intel OTC