Quoting Ville Syrjälä (2018-09-13 13:26:48) > 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. Hah, yes it is one level too deep. I think the current set of driver_features is more or less device_features? That seems like an easy job though -- though some may point out that this smells of midlayer ;) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
