Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane Color Pipeline
On Mon, 4 Sep 2023 13:44:49 + "Shankar, Uma" wrote: > > -Original Message- > > From: dri-devel On Behalf Of Pekka > > Paalanen > > Sent: Wednesday, August 30, 2023 5:59 PM > > To: Shankar, Uma > > Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar > > ; dri-de...@lists.freedesktop.org; wayland- > > de...@lists.freedesktop.org > > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed Plane > > Color Pipeline > > > > On Wed, 30 Aug 2023 08:59:36 + > > "Shankar, Uma" wrote: > > > > > > -Original Message- > > > > From: Harry Wentland > > > > Sent: Wednesday, August 30, 2023 1:10 AM > > > > To: Shankar, Uma ; > > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > Cc: Borah, Chaitanya Kumar ; > > > > wayland- de...@lists.freedesktop.org > > > > Subject: Re: [RFC 01/33] drm/doc/rfc: Add RFC document for proposed > > > > Plane Color Pipeline > > > > > > > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > Add the documentation for the new proposed Plane Color Pipeline. > > > > > > > > > > Co-developed-by: Chaitanya Kumar Borah > > > > > > > > > > Signed-off-by: Chaitanya Kumar Borah > > > > > > > > > > Signed-off-by: Uma Shankar > > > > > --- > > > > > .../gpu/rfc/plane_color_pipeline.rst | 394 > > > > > ++ > > > > > 1 file changed, 394 insertions(+) > > > > > create mode 100644 > > > > > Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > > > > > > diff --git a/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > b/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > > new file mode 100644 > > > > > index ..60ce515b6ea7 > > > > > --- /dev/null > > > > > +++ b/Documentation/gpu/rfc/plane_color_pipeline.rst > > > > ... > > > > Hi Uma! > > Thanks Pekka for the feedback and useful inputs. Hi Uma, sorry to say, but the overall feeling I get from this proposal is that it is just the current color related KMS properties wrapped in a pipeline blob. That is not the re-design I believe we are looking for, and the feeling is based on several details that are just copied from the current property design. Also the "private" stuff has to go. All the varying LUT entries, varying LUT precision, 1D/3D LUTs, varying LUT tap distribution, and parametrized curves are good development, but right now we are looking at things one step higher level: the overall color pipeline design and how to represent any operation. Most of this series is considering details below the current attention level, hence I'm paying attention only to the first few patches. More below. > > > > > +This color pipeline is then packaged within a blob for the user > > > > > +space to retrieve it. Details can be found in the next section > > > > > + > > > > > > > > Not sure I like blobs that contain other blob ids. > > > > > > It provides flexibility and helps with just one interface to > > > userspace. Its easy to handle and manage once we get the hang of it 😊. > > > > > > We can clearly define the steps of parsing and data structures to be > > > used while interpreting and parsing the blobs. > > > > Don't forget extendability. Possibly every single struct will need some > > kind of > > versioning, and then it's not simple to parse anymore. Add to that new/old > > kernel > > vs. old/new userspace, and it seems a bit nightmarish to design. > > Structure to be used to interpret the blob should be defined as UAPI only and > is not > expected to change once agreed upon. It should be interpreted like a standard > property. > So structure to be used, say for 3dLut or 1dlut or CTM operations should be > standardized > and fixed. No versioning of structure should be done and same > rules/restrictions as of UAPI > property should be applied. That sounds like a UAPI that cannot be extended, either. So in a few years we'd be looking at replacing it. Or maybe you are just re-inventing the KMS object property system as blobs? Replacing a single KMS property is much easier than replacing the foundations of the whole color pipeline design. > ... > > I have a feeling that introspection will be valuable here, to help people > > understand what their hardware could do if they had the code to use it. > > 'name' > > and 'type' being integers require a translation table to strings before > > they are > > readable, and it would be best if the kernel itself provided that > > translation. > > Name and type can be standardized in enum and well documented in the UAPI. > For all the standard hardware blocks common for all vendors and serving most > of the > common usecases, we can define standard names in enum. These can be easily > interpreted by a table as done in many cases already in driver and userspace. Yeah, but it won't help with the type-specific parameter blobs that are totally custom per each operation type. With the KMS property system we could have more generic introspection int
Re: [RFC 02/33] drm: Add color operation structure
On Mon, 4 Sep 2023 14:10:05 +
"Shankar, Uma" wrote:
> > -Original Message-
> > From: dri-devel On Behalf Of Pekka
> > Paalanen
> > Sent: Wednesday, August 30, 2023 6:30 PM
> > To: Shankar, Uma
> > Cc: intel-...@lists.freedesktop.org; Borah, Chaitanya Kumar
> > ; dri-de...@lists.freedesktop.org; wayland-
> > de...@lists.freedesktop.org
> > Subject: Re: [RFC 02/33] drm: Add color operation structure
> >
> > On Tue, 29 Aug 2023 21:33:51 +0530
> > Uma Shankar wrote:
> >
> > > From: Chaitanya Kumar Borah
> > >
> > > Each Color Hardware block will be represented uniquely in the color
> > > pipeline. Define the structure to represent the same.
> > >
> > > These color operations will form the building blocks of a color
> > > pipeline which best represents the underlying Hardware. Color
> > > operations can be re-arranged, substracted or added to create distinct
> > > color pipelines to accurately describe the Hardware blocks present in
> > > the display engine.
> > >
> > > Co-developed-by: Uma Shankar
> > > Signed-off-by: Uma Shankar
> > > Signed-off-by: Chaitanya Kumar Borah
> > > ---
> > > include/uapi/drm/drm_mode.h | 72
> > > +
> > > 1 file changed, 72 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > > index ea1b639bcb28..882479f41745 100644
> > > --- a/include/uapi/drm/drm_mode.h
> > > +++ b/include/uapi/drm/drm_mode.h
> > > @@ -943,6 +943,78 @@ struct hdr_output_metadata {
> > > };
> > > };
> > >
> > > +/**
> > > + * enum color_op_block
> > > + *
> > > + * Enums to identify hardware color blocks.
> > > + *
> > > + * @DRM_CB_PRE_CSC: LUT before the CTM unit
> > > + * @DRM_CB_CSC: CTM hardware supporting 3x3 matrix
> > > + * @DRM_CB_POST_CSC: LUT after the CTM unit
> > > + * @DRM_CB_3D_LUT: LUT hardware with coefficients for all
> > > + * color components
> > > + * @DRM_CB_PRIVATE: Vendor specific hardware unit. Vendor
> > > + * can expose a custom hardware by defining a
> > > + * color operation block with this name as
> > > + * identifier
> >
> > This naming scheme does not seem to work. It assumes a far too rigid
> > pipeline,
> > just like the old KMS property design. What if you have two other operations
> > between PRE_CSC and CSC?
> >
> > What sense do PRE_CSC and POST_CSC make if you don't happen to have a CSC
> > operation?
>
> Sure, we can re-look at the naming. However, it will be good to define some
> standard
> operations common to all vendors and keep the rest as vendor private.
My opinion is that these "names" should not even be an enum at all.
You're talking about operations, but operation is 'type', not 'name'.
There needs to be no pre-defined, hardcoded pipeline structure in the
UAPI design. Your naming scheme, and the old KMS color property design,
assume that there is such a rigid pre-defined structure that all
hardware and drivers must adhere to. That does not work.
Drivers need to be able to expose any arbitrary operations in any
arbitrary order in each pipeline, with no pre-determined or hinted
"intended use". We want to define the operations, and not say what they
should be used for. Usage examples are for accompanying documentation,
not API tokens.
This idea is at the core of the new color pipeline design we have been
discussing.
> > What if a driver put POST_CSC before PRE_CSC in its pipeline?
> >
> > What if your CSC is actually a series of three independent operations, and
> > in
> > addition you have PRE_CSC and POST_CSC?
>
> We should try to standardized the operations as much as possible and leave
> rest as
> vendor private. Current proposal allows us to do that.
>
> > 3D_LUT is an operation category, not a name. The same could be said about
> > private.
>
> Sure, will fix this.
>
> > Given that all these are also UAPI, do we also need protect old userspace
> > from
> > seeing values it does not understand?
>
> For the values userspace doesn't understand, it can ignore the blocks. We
> should ensure
> that userspace always gets a clean state wrt color hardware state and no
> baggage from
> another client should be there. With that there is no burden of disabling
> that particular
> block will be there on an older userspace.
>
> > > + */
> > > +enum color_op_block {
> > > + DRM_CB_INVAL = -1,
> > > +
> > > + DRM_CB_PRE_CSC = 0,
> > > + DRM_CB_CSC,
> > > + DRM_CB_POST_CSC,
> > > + DRM_CB_3D_LUT,
> > > +
> > > + /* Any new generic hardware block can be updated here */
> > > +
> > > + /*
> > > + * PRIVATE is kept at 255 to make it future proof and leave
> > > + * scope for any new addition
> > > + */
> > > + DRM_CB_PRIVATE = 255,
> > > + DRM_CB_MAX = DRM_CB_PRIVATE,
> > > +};
> > > +
> > > +/**
> > > + * enum color_op_type
> > > + *
> > > + * These enums are to identify the mathematical operation that
> > > + * a hardware block is capable of.
> > > + * @CURVE_1D: It
Re: [RFC 00/33] Add Support for Plane Color Pipeline
On Mon, 4 Sep 2023 14:29:56 + "Shankar, Uma" wrote: > > -Original Message- > > From: Sebastian Wick > > Sent: Thursday, August 31, 2023 2:46 AM > > To: Shankar, Uma > > Cc: Harry Wentland ; intel- > > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; wayland- > > de...@lists.freedesktop.org; Ville Syrjala ; > > Pekka > > Paalanen ; Simon Ser ; > > Melissa Wen ; Jonas Ã…dahl ; Shashank > > Sharma ; Alexander Goins ; > > Naseer Ahmed ; Christopher Braga > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > > > > -Original Message- > > > > From: Harry Wentland > > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > > To: Shankar, Uma ; > > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > Cc: wayland-devel@lists.freedesktop.org; Ville Syrjala > > > > ; Pekka Paalanen > > > > ; Simon Ser ; > > > > Melissa Wen ; Jonas Ã…dahl ; > > > > Sebastian Wick ; Shashank Sharma > > > > ; Alexander Goins ; > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > +CC Naseer and Chris, FYI > > > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole series. > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > Introduction > > > > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > > at pre-blending and post-blending phases in the color pipeline. > > > > > The current drm implementation exposes only the post-blending > > > > > color hardware blocks. Support for pre-blending hardware is missing. > > > > > There are multiple use cases where pre-blending color hardware > > > > > will be > > > > > useful: > > > > > a) Linearization of input buffers encoded in various transfer > > > > > functions. > > > > > b) Color Space conversion > > > > > c) Tone mapping > > > > > d) Frame buffer format conversion > > > > > e) Non-linearization of buffer(apply transfer function) > > > > > f) 3D Luts > > > > > > > > > > and other miscellaneous color operations. > > > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > > hardware to user-space. This will help userspace/middleware to use > > > > > display hardware for color processing and blending instead of > > > > > doing it through GPU shaders. > > > > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > > similar but you beat me to it. :) > > > > > > Thanks Harry for the useful feedback and overall collaboration on this so > > > far. > > > > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address the > > > > > same. > > > > > Broad consensus is there that we need a generic API at drm core to > > > > > suffice the use case of various HW vendors. Below are the links > > > > > capturing the discussion so far. > > > > > > > > > > Intel's Plane Color Implementation: > > > > > https://patchwork.freedesktop.org/series/90825/ > > > > > AMD's Plane Color Implementation: > > > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > > > > > > > Hackfest conclusions > > > > > > > > > > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the > > > > > industry stakeholders together and converge on a common uapi > > expectations. > > > > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia > > > > > and other prominent user-space developers and maintainers. > > > > > > > > > > Discussions happened on the uapi expectations, opens, nature of > > > > > hardware of multiple hardware vendors, challenges in generalizing > > > > > the same and the path forward. Consensus was made that drm core > > > > > should implement descriptive APIs and not go with prescriptive > > > > > APIs. DRM core should just expose the hardware capabilities; > > > > > enabling, customizing and programming the same should be done by > > > > > the user-space. Driver should just > > > > honor the user space request without doing any operations internally. > > > > > > > > > > Thanks to Simon Ser, for nicely documenting the design consensus > > > > > and an UAPI RFC which can be referred to here: > > > > > > > > > > https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze > > > > > _hD5 > > > > > > > > > > > nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1 > > Q > > > > Wn48 > > > > > 8=@emersion.fr/ > > > > > > > > > > > > > > > Design considerations > > > > > = > > > > > > > > > > Following are the important aspects taken into account while > > > > > designing the current RFC > > > > > proposal: > > > > > > > > > > 1. Individual
Re: [RFC 00/33] Add Support for Plane Color Pipeline
On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote: > On Mon, 4 Sep 2023 14:29:56 + > "Shankar, Uma" wrote: > > > > -Original Message- > > > From: Sebastian Wick > > > Sent: Thursday, August 31, 2023 2:46 AM > > > To: Shankar, Uma > > > Cc: Harry Wentland ; intel- > > > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; wayland- > > > de...@lists.freedesktop.org; Ville Syrjala > > > ; Pekka > > > Paalanen ; Simon Ser ; > > > Melissa Wen ; Jonas Ã…dahl ; Shashank > > > Sharma ; Alexander Goins ; > > > Naseer Ahmed ; Christopher Braga > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > > > > > > > -Original Message- > > > > > From: Harry Wentland > > > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > > > To: Shankar, Uma ; > > > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > > Cc: wayland-devel@lists.freedesktop.org; Ville Syrjala > > > > > ; Pekka Paalanen > > > > > ; Simon Ser ; > > > > > Melissa Wen ; Jonas Ã…dahl ; > > > > > Sebastian Wick ; Shashank Sharma > > > > > ; Alexander Goins ; > > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > > > +CC Naseer and Chris, FYI > > > > > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole series. > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > > Introduction > > > > > > > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > > > at pre-blending and post-blending phases in the color pipeline. > > > > > > The current drm implementation exposes only the post-blending > > > > > > color hardware blocks. Support for pre-blending hardware is missing. > > > > > > There are multiple use cases where pre-blending color hardware > > > > > > will be > > > > > > useful: > > > > > > a) Linearization of input buffers encoded in various transfer > > > > > >functions. > > > > > > b) Color Space conversion > > > > > > c) Tone mapping > > > > > > d) Frame buffer format conversion > > > > > > e) Non-linearization of buffer(apply transfer function) > > > > > > f) 3D Luts > > > > > > > > > > > > and other miscellaneous color operations. > > > > > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > > > hardware to user-space. This will help userspace/middleware to use > > > > > > display hardware for color processing and blending instead of > > > > > > doing it through GPU shaders. > > > > > > > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > > > similar but you beat me to it. :) > > > > > > > > Thanks Harry for the useful feedback and overall collaboration on this > > > > so far. > > > > > > > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address the > > > > > > same. > > > > > > Broad consensus is there that we need a generic API at drm core to > > > > > > suffice the use case of various HW vendors. Below are the links > > > > > > capturing the discussion so far. > > > > > > > > > > > > Intel's Plane Color Implementation: > > > > > > https://patchwork.freedesktop.org/series/90825/ > > > > > > AMD's Plane Color Implementation: > > > > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > > > > > > > > > > Hackfest conclusions > > > > > > > > > > > > > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the > > > > > > industry stakeholders together and converge on a common uapi > > > expectations. > > > > > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia > > > > > > and other prominent user-space developers and maintainers. > > > > > > > > > > > > Discussions happened on the uapi expectations, opens, nature of > > > > > > hardware of multiple hardware vendors, challenges in generalizing > > > > > > the same and the path forward. Consensus was made that drm core > > > > > > should implement descriptive APIs and not go with prescriptive > > > > > > APIs. DRM core should just expose the hardware capabilities; > > > > > > enabling, customizing and programming the same should be done by > > > > > > the user-space. Driver should just > > > > > honor the user space request without doing any operations internally. > > > > > > > > > > > > > > > > > Thanks to Simon Ser, for nicely documenting the design consensus > > > > > > and an UAPI RFC which can be referred to here: > > > > > > > > > > > > https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze > > > > > > _hD5 > > > > > > > > > > > > > > nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1 > > > Q > > > >
Re: [RFC 00/33] Add Support for Plane Color Pipeline
On Tue, Sep 05, 2023 at 02:33:04PM +0200, Sebastian Wick wrote: > On Tue, Sep 05, 2023 at 02:33:26PM +0300, Pekka Paalanen wrote: > > On Mon, 4 Sep 2023 14:29:56 + > > "Shankar, Uma" wrote: > > > > > > -Original Message- > > > > From: Sebastian Wick > > > > Sent: Thursday, August 31, 2023 2:46 AM > > > > To: Shankar, Uma > > > > Cc: Harry Wentland ; intel- > > > > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; wayland- > > > > de...@lists.freedesktop.org; Ville Syrjala > > > > ; Pekka > > > > Paalanen ; Simon Ser > > > > ; > > > > Melissa Wen ; Jonas Ã…dahl ; Shashank > > > > Sharma ; Alexander Goins ; > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote: > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: Harry Wentland > > > > > > Sent: Wednesday, August 30, 2023 12:56 AM > > > > > > To: Shankar, Uma ; > > > > > > intel-...@lists.freedesktop.org; dri- de...@lists.freedesktop.org > > > > > > Cc: wayland-devel@lists.freedesktop.org; Ville Syrjala > > > > > > ; Pekka Paalanen > > > > > > ; Simon Ser ; > > > > > > Melissa Wen ; Jonas Ã…dahl ; > > > > > > Sebastian Wick ; Shashank Sharma > > > > > > ; Alexander Goins ; > > > > > > Naseer Ahmed ; Christopher Braga > > > > > > > > > > > > Subject: Re: [RFC 00/33] Add Support for Plane Color Pipeline > > > > > > > > > > > > +CC Naseer and Chris, FYI > > > > > > > > > > > > See https://patchwork.freedesktop.org/series/123024/ for whole > > > > > > series. > > > > > > > > > > > > On 2023-08-29 12:03, Uma Shankar wrote: > > > > > > > Introduction > > > > > > > > > > > > > > > > > > > > > Modern hardwares have various color processing capabilities both > > > > > > > at pre-blending and post-blending phases in the color pipeline. > > > > > > > The current drm implementation exposes only the post-blending > > > > > > > color hardware blocks. Support for pre-blending hardware is > > > > > > > missing. > > > > > > > There are multiple use cases where pre-blending color hardware > > > > > > > will be > > > > > > > useful: > > > > > > > a) Linearization of input buffers encoded in various transfer > > > > > > > functions. > > > > > > > b) Color Space conversion > > > > > > > c) Tone mapping > > > > > > > d) Frame buffer format conversion > > > > > > > e) Non-linearization of buffer(apply transfer function) > > > > > > > f) 3D Luts > > > > > > > > > > > > > > and other miscellaneous color operations. > > > > > > > > > > > > > > Hence, there is a need to expose the color capabilities of the > > > > > > > hardware to user-space. This will help userspace/middleware to use > > > > > > > display hardware for color processing and blending instead of > > > > > > > doing it through GPU shaders. > > > > > > > > > > > > > > > > > > > Thanks, Uma, for sending this. I've been working on something > > > > > > similar but you beat me to it. :) > > > > > > > > > > Thanks Harry for the useful feedback and overall collaboration on > > > > > this so far. > > > > > > > > > > > > > > > > > > > Work done so far and relevant references > > > > > > > > > > > > > > > > > > > > > Some implementation is done by Intel and AMD/Igalia to address > > > > > > > the same. > > > > > > > Broad consensus is there that we need a generic API at drm core to > > > > > > > suffice the use case of various HW vendors. Below are the links > > > > > > > capturing the discussion so far. > > > > > > > > > > > > > > Intel's Plane Color Implementation: > > > > > > > https://patchwork.freedesktop.org/series/90825/ > > > > > > > AMD's Plane Color Implementation: > > > > > > > https://patchwork.freedesktop.org/series/116862/ > > > > > > > > > > > > > > > > > > > > > Hackfest conclusions > > > > > > > > > > > > > > > > > > > > > HDR/Color Hackfest was organised by Redhat to bring all the > > > > > > > industry stakeholders together and converge on a common uapi > > > > expectations. > > > > > > > Participants from Intel, AMD, Nvidia, Collabora, Redhat, Igalia > > > > > > > and other prominent user-space developers and maintainers. > > > > > > > > > > > > > > Discussions happened on the uapi expectations, opens, nature of > > > > > > > hardware of multiple hardware vendors, challenges in generalizing > > > > > > > the same and the path forward. Consensus was made that drm core > > > > > > > should implement descriptive APIs and not go with prescriptive > > > > > > > APIs. DRM core should just expose the hardware capabilities; > > > > > > > enabling, customizing and programming the same should be done by > > > > > > > the user-space. Driver should just > > > > > > honor the user space request without doing any operations > > > > > > internally. > > > > > > > > > > > > > > Thanks to Simon Ser, for nicely documenti
