[Intel-gfx] [PATCH] drm/i915: Remove fb pitch limit for no display

[Ville Syrjälä]

On Thu, Sep 13, 2018 at 12:05:49PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-09-13 11:56:56)
> > On Thu, Sep 13, 2018 at 11:39:23AM +0100, Chris Wilson wrote:
> > > If there is not a display (and so no CRTCs) then there is no upper limit
> > > to the framebuffer pitch imposed by the CRTC.
> > 
> > Should we still allow you to create framebuffers in that case?
> 
> Up to you, imho is that fb are just bo with a bit of description. I
> didn't see much harm in creating an fb even if it was never going to be
> attached to any pipe. I don't have a solid usecase, just feels like it
> reduces the impact on the API.

To me it feels a bit like giving userspace false hope that they
can actually do something with the fb later.

> 
> Hmm, however if we
> 	if (num_pipes == 0) driver_features &= ~DRIVER_MODESET;
> we will kill the unusable API at the ioctl boundary.

That seems a bit wrong. We'd really want to device_features for
something like that. Not sure how many things we have in the driver
struct that really ought to be under the device.

> 
> > If yes then my plan to also query the planes which pixel formats/modifiers
> > to accept in addfb is going to hit hard times.
> 
> Spreading an ugly if !plane around :(

Should just be for_each_plane() and I guess if none are there the
addfb would get rejected as the format wouldn't match anything.
But I haven't actually figured out how to do this in the best way.

Another option would be to cache the union of all format/modifier
combos of all planes somewhere and check against that (should be
slightly more efficient as we wouldn't check the same thing many
times). And in that case I guess we could always add some kind
of fallback of say just XRGB8888 for the num_pipes==0 case,
should we think there is some benefit to allowing it.

-- 
Ville Syrjälä
Intel