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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
