Re: [PATCH] color-management: Add HDR-metadata support
Pekka Paalanen writes: > On Tue, 19 Mar 2019 11:46:17 +0530 > Harish Krupo wrote: > >> Hi Ankit, >> >> Nautiyal, Ankit K writes: >> >> > Hi Harish, >> > >> > Thanks for the correction and suggestions. >> > Please find my responses inline: >> > >> > On 3/18/2019 9:40 PM, Harish Krupo wrote: >> >> Hi Ankit, >> >> >> >> Nautiyal, Ankit K writes: >> >> >> >>> From: Ankit Nautiyal >> >>> >> >>> This patch adds HDR-metadata support in the color-management-protocol. >> >>> It enables a client to: >> >>> - know if an output is HDR capable. >> >>> - set HDR-metadata values, received from an HDR content, for a surface. >> >>> >> >>> The HDR-metadata values : MAX_CLL, MAX_FALL, MAX_LUMINANCE, >> >>> MIN LUMINANCE can be sent from the client to compositor, which can >> >>> inturn send these to kernel. Kernel can finally send these values in >> >> >> >> typo: in turn :) >> > >> > Thanks for catching this. :) >> > >> >> >> >>> AVI-INFOFRAMES to the HDR display to provide an idea of the brightness >> >>> of the content. The display can use this information to adapt itself >> >>> for a better viewing experience. >> >> >> >> You can also add that this information could be used for tone mapping >> >> when composing along with other buffers. >> >> >> >>> >> >>> Signed-off-by: Ankit Nautiyal >> >>> --- >> >>> .../color-management-unstable-v1.xml | 48 >> >>> +- >> >>> 1 file changed, 46 insertions(+), 2 deletions(-) >> >>> >> >>> diff --git a/unstable/color-management/color-management-unstable-v1.xml >> >>> b/unstable/color-management/color-management-unstable-v1.xml >> >>> index 7b4d08e..58a41a1 100644 >> >>> --- a/unstable/color-management/color-management-unstable-v1.xml >> >>> +++ b/unstable/color-management/color-management-unstable-v1.xml >> >>> @@ -119,7 +119,15 @@ >> >>> >> >>> >> >>> >> >>> - >> >>> + >> >>> + >> >>> +This event is sent after creating a zwp_color_management_output >> >>> +(see zwp_color_manager.get_color_management_output) and tells >> >>> about the >> >>> +HDR capability of an output. A value of '1' indicates that the >> >>> output >> >>> +is HDR capable, and '0' indicates a non-HDR output. >> >> >> >> Can the client span across outputs? If so what will the client receive? >> >> 1 or 0? >> > >> > The interface zwp_color_management_output is associated with a single >> > output. If >> > a client spans across multiple outputs, it will have to get two different >> > zwp_color_management for each of the outputs. >> > Each might provide a separate value, (as in case of one HDR and one non HDR >> > display), client can still set the hdr-metadata for the surface. It >> > depends on >> > the compositor as to what it wants to do with the given values. >> > >> >> Yeah. My bad. >> A different question this time :) >> The event "whether an output supports HDR or not" seems to be lacking. >> What can the client do with this information? Maybe document the example >> behaviour? >> Typically the client would need the HDR display's metadata if it were to >> do something meaningful like apply tone mapping or such. But this might >> be complicated when the client spans multiple outputs. > > Hi, > > this should include the monitor's HDR metadata indeed. Otherwise the > client cannot do the tone mapping specific to the output which would > allow direct scanout of the client buffer in the best case. > > You could have two events: "sdr" without any metadata, and "hdr" with > arguments. Clients should be prepared for the data to change on the > fly, if the compositor e.g. decides to force SDR mode after being in > HDR mode on the output. It's the same thing as what the > color_space_changed event signals, except color space is a complex > object rather than just some numbers. > Hi Pekka, One more thing:
Re: [PATCH] color-management: Add HDR-metadata support
Hi Ankit, Nautiyal, Ankit K writes: > Hi Harish, > > Thanks for the correction and suggestions. > Please find my responses inline: > > On 3/18/2019 9:40 PM, Harish Krupo wrote: >> Hi Ankit, >> >> Nautiyal, Ankit K writes: >> >>> From: Ankit Nautiyal >>> >>> This patch adds HDR-metadata support in the color-management-protocol. >>> It enables a client to: >>> - know if an output is HDR capable. >>> - set HDR-metadata values, received from an HDR content, for a surface. >>> >>> The HDR-metadata values : MAX_CLL, MAX_FALL, MAX_LUMINANCE, >>> MIN LUMINANCE can be sent from the client to compositor, which can >>> inturn send these to kernel. Kernel can finally send these values in >> >> typo: in turn :) > > Thanks for catching this. :) > >> >>> AVI-INFOFRAMES to the HDR display to provide an idea of the brightness >>> of the content. The display can use this information to adapt itself >>> for a better viewing experience. >> >> You can also add that this information could be used for tone mapping >> when composing along with other buffers. >> >>> >>> Signed-off-by: Ankit Nautiyal >>> --- >>> .../color-management-unstable-v1.xml | 48 >>> +- >>> 1 file changed, 46 insertions(+), 2 deletions(-) >>> >>> diff --git a/unstable/color-management/color-management-unstable-v1.xml >>> b/unstable/color-management/color-management-unstable-v1.xml >>> index 7b4d08e..58a41a1 100644 >>> --- a/unstable/color-management/color-management-unstable-v1.xml >>> +++ b/unstable/color-management/color-management-unstable-v1.xml >>> @@ -119,7 +119,15 @@ >>> >>> >>> >>> - >>> + >>> + >>> + This event is sent after creating a zwp_color_management_output >>> + (see zwp_color_manager.get_color_management_output) and tells about the >>> + HDR capability of an output. A value of '1' indicates that the output >>> + is HDR capable, and '0' indicates a non-HDR output. >> >> Can the client span across outputs? If so what will the client receive? >> 1 or 0? > > The interface zwp_color_management_output is associated with a single output. > If > a client spans across multiple outputs, it will have to get two different > zwp_color_management for each of the outputs. > Each might provide a separate value, (as in case of one HDR and one non HDR > display), client can still set the hdr-metadata for the surface. It depends on > the compositor as to what it wants to do with the given values. > Yeah. My bad. A different question this time :) The event "whether an output supports HDR or not" seems to be lacking. What can the client do with this information? Maybe document the example behaviour? Typically the client would need the HDR display's metadata if it were to do something meaningful like apply tone mapping or such. But this might be complicated when the client spans multiple outputs. >> >>> + >>> + >>> + >>> >>> >>> >>> @@ -171,7 +179,43 @@ >>> >>> >>> >>> - >>> + >>> + >>> + Set the HDR-metadata for the underlying surface. The HDR-metadata is >>> + double buffered, and will be applied at the time wl_surface.commit of >>> + the corresponding wl_surface is called. >>> + The HDR-metadata constitutes of MAX-CLL, MAX-FALL, Max Luminance and >>> + Min Luminance as defined by SMPTE ST.2086. The clients get these values >>> + for an HDR video via ffmpeg for a video stream/file. >>> + >>> + MAX-CLL (Maximum Content Light Level) tells the brightest pixel in the >>> + entire stream/file in nits. MAX-FALL (Maximum Frame Average Light Level) >>> + tells the highest frame average brightness in nits for a single frame. >>> + Max and Min Luminance tells the max/min Luminance for the mastering >>> + display. All except for Minimum Luminace, can be represented by integer, >>> + as they take values of the order of hundreds of nits. >>> + For Minimum Luminance, fixed type is used so that it can take smaller >>> + decimal values, which can be converted to and from double. >>> + >>> + For setting color-primaries as part of HDR-metadata, the client should >>> + manufacture the icc profile and then use the zwp_color_manager int
Re: [PATCH] color-management: Add HDR-metadata support
Hi Ankit, Nautiyal, Ankit K writes: > From: Ankit Nautiyal > > This patch adds HDR-metadata support in the color-management-protocol. > It enables a client to: > - know if an output is HDR capable. > - set HDR-metadata values, received from an HDR content, for a surface. > > The HDR-metadata values : MAX_CLL, MAX_FALL, MAX_LUMINANCE, > MIN LUMINANCE can be sent from the client to compositor, which can > inturn send these to kernel. Kernel can finally send these values in typo: in turn :) > AVI-INFOFRAMES to the HDR display to provide an idea of the brightness > of the content. The display can use this information to adapt itself > for a better viewing experience. You can also add that this information could be used for tone mapping when composing along with other buffers. > > Signed-off-by: Ankit Nautiyal > --- > .../color-management-unstable-v1.xml | 48 > +- > 1 file changed, 46 insertions(+), 2 deletions(-) > > diff --git a/unstable/color-management/color-management-unstable-v1.xml > b/unstable/color-management/color-management-unstable-v1.xml > index 7b4d08e..58a41a1 100644 > --- a/unstable/color-management/color-management-unstable-v1.xml > +++ b/unstable/color-management/color-management-unstable-v1.xml > @@ -119,7 +119,15 @@ > > > > - > + > + > + This event is sent after creating a zwp_color_management_output > + (see zwp_color_manager.get_color_management_output) and tells about the > + HDR capability of an output. A value of '1' indicates that the output > + is HDR capable, and '0' indicates a non-HDR output. Can the client span across outputs? If so what will the client receive? 1 or 0? > + > + > + > > > > @@ -171,7 +179,43 @@ > > > > - > + > + > + Set the HDR-metadata for the underlying surface. The HDR-metadata is > + double buffered, and will be applied at the time wl_surface.commit of > + the corresponding wl_surface is called. > + The HDR-metadata constitutes of MAX-CLL, MAX-FALL, Max Luminance and > + Min Luminance as defined by SMPTE ST.2086. The clients get these values > + for an HDR video via ffmpeg for a video stream/file. > + > + MAX-CLL (Maximum Content Light Level) tells the brightest pixel in the > + entire stream/file in nits. MAX-FALL (Maximum Frame Average Light Level) > + tells the highest frame average brightness in nits for a single frame. > + Max and Min Luminance tells the max/min Luminance for the mastering > + display. All except for Minimum Luminace, can be represented by integer, > + as they take values of the order of hundreds of nits. > + For Minimum Luminance, fixed type is used so that it can take smaller > + decimal values, which can be converted to and from double. > + > + For setting color-primaries as part of HDR-metadata, the client should > + manufacture the icc profile and then use the zwp_color_manager interface > + to get the color-space, (see zwp_color_manager.create_color_space). > + The request set_color_space can then be used to set the color-space. > + > + A client may request for setting the HDR-metadata for a surface, even if > + there is no HDR-capable output, compositor should handle such cases. > + "Should" sounds a bit assertive. Maybe drop the sentence? > + The HDR-metadata should be initialized with '-1' for a surface, > + signifying that the values are invalid. So, If a client does not set > + hdr-metadata values for a surface, i.e. does not request > + set_hdr_metadata default value of '-1' will be there, telling the > + compositor that there is no HDR-metadata for that surface. > + > + > + > + max_cll and max_fall are uints but max_luminance is of fixed type. Also, what happens when the clients wants to reset the hdr metadata? Would it set -1 to all the values to notify of this change? I think all of them should be of fixed types to be able to send -1. > + > + > > > Thank you Regards Harish Krupo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Clang format config for Weston
Hi,
I dumped the llvm configuration from clang-format, edited it and pruned
all the unneeded configs (like configs for other langauges).
I have to agree with Simon. It is indeed impossible to be able to get
the requirements exactly right with clang. I managed to get almost all
the configs right but some of the style options either don't have a
config or the existing config options aren't sufficient. For example the
`AlignAfterOpenBracket: Align`
for some reason doesn't work correctly for function declarations. Some
corrections don't seem to have a control (at least I couldn't find one).
For example clang-format changed this:
static const EGLint gl_renderer_opaque_attribs[] = {
EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
EGL_RED_SIZE, 1,
EGL_GREEN_SIZE, 1,
EGL_BLUE_SIZE, 1,
EGL_ALPHA_SIZE, 0,
EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
EGL_NONE
};
to
static const EGLint gl_renderer_opaque_attribs[] = { EGL_SURFACE_TYPE,
EGL_WINDOW_BIT,
EGL_RED_SIZE,
1,
EGL_GREEN_SIZE,
1,
EGL_BLUE_SIZE,
1,
EGL_ALPHA_SIZE,
0,
EGL_RENDERABLE_TYPE,
EGL_OPENGL_ES2_BIT,
EGL_NONE };
and I couldn't find a way of controlling it. For people who are interested
in experimenting, please find my config below. Other option would be to
use a .editorconfig/.dir-locals.el but I don't think they can be used
with the CI. If anyone has other ideas on implementing code checking
which can be enabled on the CI, please do suggest :)
Config:
AlignAfterOpenBracket: Align
AlignConsecutiveAssignments: false
AlignConsecutiveDeclarations: false
AlignEscapedNewlines: Right
AlignOperands: true
AlignTrailingComments: true
AllowAllParametersOfDeclarationOnNextLine: false
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: false
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterReturnType: TopLevel
AlwaysBreakBeforeMultilineStrings: false
BinPackArguments: true
BinPackParameters: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Linux
BreakBeforeTernaryOperators: false
BreakStringLiterals: true
ColumnLimit: 80
ContinuationIndentWidth: 8
Cpp11BracedListStyle: false
DerivePointerAlignment: true
DisableFormat: false
ExperimentalAutoDetectBinPacking: false
ForEachMacros: ['wl_list_for_each', 'wl_list_for_each_safe',
'wl_list_for_each_reverse']
IncludeBlocks: Preserve
IncludeCategories:
- Regex: '^"(llvm|llvm-c|clang|clang-c)/'
Priority:2
- Regex: '^(<|"(gtest|gmock|isl|json)/)'
Priority:3
- Regex: '.*'
Priority:1
IncludeIsMainRegex: '(_test)?$'
IndentCaseLabels: false
IndentPPDirectives: None
IndentWidth: 8
IndentWrappedFunctionNames: false
KeepEmptyLinesAtTheStartOfBlocks: false
MacroBlockBegin: ''
MacroBlockEnd: ''
MaxEmptyLinesToKeep: 1
#PenaltyBreakAssignment: 2
#PenaltyBreakBeforeFirstCallParameter: 19
#PenaltyBreakComment: 300
#PenaltyBreakFirstLessLess: 120
#PenaltyBreakString: 1000
#PenaltyBreakTemplateDeclaration: 10
#PenaltyExcessCharacter: 100
#PenaltyReturnTypeOnItsOwnLine: 60
PointerAlignment: Right
ReflowComments: true
SortIncludes:true
SpaceAfterCStyleCast: false
SpaceBeforeAssignmentOperators: true
SpaceBeforeParens: ControlStatements
SpaceInEmptyParentheses: false
SpacesBeforeTrailingComments: 1
SpacesInContainerLiterals: true
SpacesInParentheses: false
SpacesInCStyleCastParentheses: false
SpacesInSquareBrackets: false
TabWidth: 8
UseTab: Always
Thank you
Regards
Harish Krupo
Harish Krupo writes:
> Pekka Paalanen writes:
>
>> On Thu, 14 Mar 2019 18:11:47 +0530
>> Harish Krupo wrote:
>>
>>> Pekka Paalanen writes:
>>
>>> > FYI, one thing I would never want to see in a patch is adding
>>> > '/* clang-format off */' kind of directives into code.
>>> >
>>>
>>> /* clang-format off */ directive is supposed to be used sparingly. If
>>> the whole code is commented out that way then I believe the reviewer
>>> should point that out. We could also add a check in the CI to
>>> ensure that the /* cl
Re: Clang format config for Weston
Hi Simon, Simon Ser writes: > On Thursday, March 14, 2019 12:20 PM, Harish Krupo > wrote: > >> Hi Pekka, >> >> Pekka Paalanen ppaala...@gmail.com writes: >> >> > On Thu, 14 Mar 2019 16:01:08 +0530 >> > Harish Krupo harish.krupo@intel.com wrote: >> > >> > > Hi, >> > > I have written a clang format file based on this example [1], to >> > > match the coding style here [2]. Does the below config look okay or >> > > should something be changed? >> > > If people are interested, I can open a MR for this. This could also be >> > > used in the CI to warn/abort if a patch isn't according to the coding >> > > style. >> > > The config: >> > > BasedOnStyle: LLVM >> > > IndentWidth: 8 >> > > TabWidth: 8 >> > > UseTab: Always >> > > BreakBeforeBraces: Linux >> > > AllowShortIfStatementsOnASingleLine: false >> > > IndentCaseLabels: false >> > > AlwaysBreakAfterReturnType: TopLevel >> > > [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html#examples >> > > [2] >> > > https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md#coding-style >> > >> > Hi Harish, >> > I guess that depends on how different that is from the existing code >> > base style. Seeing the warning list generated for the existing code >> > would tell a lot, I doubt it would be empty. >> >> Okay, I see what you mean. Running clang format on >> libweston/gl-renderer.c does generate a few false positives. Some of >> them could be corrected by setting other config options. > > An issue with clang-format is that getting a perfect config file is > really tedious (and sometimes impossible). > > I'll try improving it a little. Sure. Please do :) > >> > Is the LLVM style something guaranteed to not change? >> >> I am not sure about this :( > > We can always copy-pasta the LLVM style. > >> > Using it in CI might be an attractive idea, but I wonder if it would >> > result in many false warnings. Some aspects of coding style are always >> > somewhat vague and need to adapt to the code at hand to look nice to a >> > human rather than follow some rigorous rules. If it leaves such things >> > as is and checks only those that should follow rigorous rules, that >> > would be nice. >> >> All the config options that Clang-format uses to format code is given in >> [1]. It leaves the rest to the user. We would have to define all (at >> least most) of those options for weston if we want to use this with the >> CI. Consequence of doing this would make the BasedOnStyle: LLVM option >> unneeded. >> >> Thank you >> Regards >> Harish Krupo >> >> [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Clang format config for Weston
Pekka Paalanen writes: > On Thu, 14 Mar 2019 18:11:47 +0530 > Harish Krupo wrote: > >> Pekka Paalanen writes: > >> > FYI, one thing I would never want to see in a patch is adding >> > '/* clang-format off */' kind of directives into code. >> > >> >> /* clang-format off */ directive is supposed to be used sparingly. If >> the whole code is commented out that way then I believe the reviewer >> should point that out. We could also add a check in the CI to >> ensure that the /* clang-format off */ and /* clang-format on */ pair >> don't span more than a few lines at a time. > > Hi Harish, > > no, I really mean they should never be used at all. If they are > actually necessary even once, then we did something wrong: we made it > an error in CI instead of only a warning, the format checker was was a > bad choice, or the format definition is off. > > If the directive is only needed sparingly, then it is not needed at > all, because reviewers can just say the checker in CI is wrong and merge > the patch with style warnings. If that becomes a hindrance, then it's > not "sparingly" anymore. Makes sense. I will create a config with all the necessary options for clang-format and probably we can then discuss if they make sense. Thank you Regards Harish Krupo > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Clang format config for Weston
Pekka Paalanen writes: > On Thu, 14 Mar 2019 16:57:08 +0530 > Harish Krupo wrote: > >> Harish Krupo writes: >> >> > Hi Pekka, >> > >> > Pekka Paalanen writes: >> > >> >> On Thu, 14 Mar 2019 16:01:08 +0530 >> >> Harish Krupo wrote: >> >> >> >>> Hi, >> >>> >> >>> I have written a clang format file based on this example [1], to >> >>> match the coding style here [2]. Does the below config look okay or >> >>> should something be changed? >> >>> If people are interested, I can open a MR for this. This could also be >> >>> used in the CI to warn/abort if a patch isn't according to the coding >> >>> style. >> >>> >> >>> The config: >> >>> BasedOnStyle: LLVM >> >>> IndentWidth: 8 >> >>> TabWidth: 8 >> >>> UseTab: Always >> >>> BreakBeforeBraces: Linux >> >>> AllowShortIfStatementsOnASingleLine: false >> >>> IndentCaseLabels: false >> >>> AlwaysBreakAfterReturnType: TopLevel >> >>> >> >>> [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html#examples >> >>> [2] >> >>> https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md#coding-style >> >>> >> >> >> >> Hi Harish, >> >> >> >> I guess that depends on how different that is from the existing code >> >> base style. Seeing the warning list generated for the existing code >> >> would tell a lot, I doubt it would be empty. >> >> >> > >> > Okay, I see what you mean. Running clang format on >> > libweston/gl-renderer.c does generate a few false positives. Some of >> > them could be corrected by setting other config options. >> > >> >> Is the LLVM style something guaranteed to not change? >> > >> > I am not sure about this :( >> > >> >> >> >> Using it in CI might be an attractive idea, but I wonder if it would >> >> result in many false warnings. Some aspects of coding style are always >> >> somewhat vague and need to adapt to the code at hand to look nice to a >> >> human rather than follow some rigorous rules. If it leaves such things >> >> as is and checks only those that should follow rigorous rules, that >> >> would be nice. >> >> >> > >> > All the config options that Clang-format uses to format code is given in >> > [1]. It leaves the rest to the user. We would have to define all (at >> > least most) of those options for weston if we want to use this with the >> > CI. Consequence of doing this would make the BasedOnStyle: LLVM option >> > unneeded. >> > >> >> Another thing to note is that clang format provides a tool called >> clang-format-diff which runs the checker only for diffs. This way we >> don't have to change the existing code. Only new changes can be checked >> this way. It can be run as follows: >> `git diff | clang-format-diff.py -p1 -style=file` >> or >> `git show | clang-format-diff.py -p1 -style=file` > > Hi, > > yes, I was already assuming there is a way to run it only on new > patches. > > The test with existing code however is a good indication on how far the > clang format definition would go: if the places it highlighted were > fixed, would the readability get better or worse. > > We should go over each pattern Clang highlights and see which way is > better. Once it gets into CI, people will be hell-bent to fix > everything it points out, even if it's just a warning rather than > failure. > Understood. The behaviour for each of the pattern that it checks is documented. We would need to decide on what action it should to take on those patterns for weston. > Style checker as part of CI would be awesome, we just have to make sure > it is more help than annoyance. > Agreed. > FYI, one thing I would never want to see in a patch is adding > '/* clang-format off */' kind of directives into code. > /* clang-format off */ directive is supposed to be used sparingly. If the whole code is commented out that way then I believe the reviewer should point that out. We could also add a check in the CI to ensure that the /* clang-format off */ and /* clang-format on */ pair don't span more than a few lines at a time. Thank you Regards Harish Krupo > > Thanks, > pq > >> >> > Thank you >> > Regards >> > Harish Krupo >> > >> > [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html >> ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Clang format config for Weston
Harish Krupo writes: > Hi Pekka, > > Pekka Paalanen writes: > >> On Thu, 14 Mar 2019 16:01:08 +0530 >> Harish Krupo wrote: >> >>> Hi, >>> >>> I have written a clang format file based on this example [1], to >>> match the coding style here [2]. Does the below config look okay or >>> should something be changed? >>> If people are interested, I can open a MR for this. This could also be >>> used in the CI to warn/abort if a patch isn't according to the coding >>> style. >>> >>> The config: >>> BasedOnStyle: LLVM >>> IndentWidth: 8 >>> TabWidth: 8 >>> UseTab: Always >>> BreakBeforeBraces: Linux >>> AllowShortIfStatementsOnASingleLine: false >>> IndentCaseLabels: false >>> AlwaysBreakAfterReturnType: TopLevel >>> >>> [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html#examples >>> [2] >>> https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md#coding-style >> >> Hi Harish, >> >> I guess that depends on how different that is from the existing code >> base style. Seeing the warning list generated for the existing code >> would tell a lot, I doubt it would be empty. >> > > Okay, I see what you mean. Running clang format on > libweston/gl-renderer.c does generate a few false positives. Some of > them could be corrected by setting other config options. > >> Is the LLVM style something guaranteed to not change? > > I am not sure about this :( > >> >> Using it in CI might be an attractive idea, but I wonder if it would >> result in many false warnings. Some aspects of coding style are always >> somewhat vague and need to adapt to the code at hand to look nice to a >> human rather than follow some rigorous rules. If it leaves such things >> as is and checks only those that should follow rigorous rules, that >> would be nice. >> > > All the config options that Clang-format uses to format code is given in > [1]. It leaves the rest to the user. We would have to define all (at > least most) of those options for weston if we want to use this with the > CI. Consequence of doing this would make the BasedOnStyle: LLVM option > unneeded. > Another thing to note is that clang format provides a tool called clang-format-diff which runs the checker only for diffs. This way we don't have to change the existing code. Only new changes can be checked this way. It can be run as follows: `git diff | clang-format-diff.py -p1 -style=file` or `git show | clang-format-diff.py -p1 -style=file` > Thank you > Regards > Harish Krupo > > [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Clang format config for Weston
Hi Pekka, Pekka Paalanen writes: > On Thu, 14 Mar 2019 16:01:08 +0530 > Harish Krupo wrote: > >> Hi, >> >> I have written a clang format file based on this example [1], to >> match the coding style here [2]. Does the below config look okay or >> should something be changed? >> If people are interested, I can open a MR for this. This could also be >> used in the CI to warn/abort if a patch isn't according to the coding >> style. >> >> The config: >> BasedOnStyle: LLVM >> IndentWidth: 8 >> TabWidth: 8 >> UseTab: Always >> BreakBeforeBraces: Linux >> AllowShortIfStatementsOnASingleLine: false >> IndentCaseLabels: false >> AlwaysBreakAfterReturnType: TopLevel >> >> [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html#examples >> [2] >> https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md#coding-style > > Hi Harish, > > I guess that depends on how different that is from the existing code > base style. Seeing the warning list generated for the existing code > would tell a lot, I doubt it would be empty. > Okay, I see what you mean. Running clang format on libweston/gl-renderer.c does generate a few false positives. Some of them could be corrected by setting other config options. > Is the LLVM style something guaranteed to not change? I am not sure about this :( > > Using it in CI might be an attractive idea, but I wonder if it would > result in many false warnings. Some aspects of coding style are always > somewhat vague and need to adapt to the code at hand to look nice to a > human rather than follow some rigorous rules. If it leaves such things > as is and checks only those that should follow rigorous rules, that > would be nice. > All the config options that Clang-format uses to format code is given in [1]. It leaves the rest to the user. We would have to define all (at least most) of those options for weston if we want to use this with the CI. Consequence of doing this would make the BasedOnStyle: LLVM option unneeded. Thank you Regards Harish Krupo [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Clang format config for Weston
Hi, I have written a clang format file based on this example [1], to match the coding style here [2]. Does the below config look okay or should something be changed? If people are interested, I can open a MR for this. This could also be used in the CI to warn/abort if a patch isn't according to the coding style. The config: BasedOnStyle: LLVM IndentWidth: 8 TabWidth: 8 UseTab: Always BreakBeforeBraces: Linux AllowShortIfStatementsOnASingleLine: false IndentCaseLabels: false AlwaysBreakAfterReturnType: TopLevel [1] https://clang.llvm.org/docs/ClangFormatStyleOptions.html#examples [2] https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md#coding-style ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v2 1/1] unstable: add color management protocol
r space to surfaces.
>> +
>> +
>> +
>> +
>> +render intents
>
> This could probably be expanded to at least be a sentence.
>
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +Well-known color spaces
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +These fatal protocol errors may be emitted in response to
>> +illegal color management requests.
>> +
>> +
>> +
>> +
>> +
>> +
>> +Set the color space of a surface. The color space is double
>> buffered,
>> +and will be applied at the time wl_surface.commit of the
>> corresponding
>> +wl_surface is called.
>
> Wording: "and will be applied on the next wl_surface.commit"
>
>> +The render intent gives the compositor a hint what to optimize for
>> +in color space conversions.
>> +
>> +If a surface has no color space set, sRGB and an arbitrary render
>> +intent will be assumed.
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +Request color space feedback for the current content submission
>> +on the given surface. This creates a new color_space_feedback
>> +object, which will deliver the feedback information once. If
>> +multiple color_space_feedback objects are created for the same
>> +submission, they will all deliver the same information.
>> +
>> +For details on what information is returned, see the
>> +color_space_feedback interface.
>> +
>> +
>> + > interface="zwp_color_space_feedback_v1"/>
>> +
>> +
>> +
>
> Maybe this should be named "create_color_space_from_icc"?
>
>> +
>> +Create a color space from an ICC profile. Only three channel
>> +display profiles are allowed.
>> +
>> +
>> +
>> +
>> +
>> +
>
> Generally events that create objects are just called with the name of the
> object
> ("color_space").
>
> This uses server-side created resources. This should be done with care, see:
> https://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html
>
> A way to prevent races is to add:
>
> - A "stop" request that asks the compositor to stop sending events and destroy
> the object
> - A "finished" event that notifies the client that the compositor has
> destroyed
> the object. The client will then be able to release resources.
>
Instead of sending objects maybe we could send the "well known" enum
values? Based on this the client could choose to create only a subset of
the color space objects by calling create_color_space_from_well_known.
This way the compositor doesn't need to allocate server side memory for
all well-known color spaces?
Thank you
Regards
Harish Krupo
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[v2 1/2] hdr-metadata: Add protocol for static HDR metadata
v2: Add description for the hdr_surface requests, fix style and typo (Simon Ser) Signed-off-by: Harish Krupo --- Makefile.am | 1 + unstable/hdr-metadata/README | 4 + .../hdr-metadata/hdr-metadata-unstable-v1.xml | 115 ++ 3 files changed, 120 insertions(+) create mode 100644 unstable/hdr-metadata/README create mode 100644 unstable/hdr-metadata/hdr-metadata-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 345ae6a..8e70a9f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -23,6 +23,7 @@ unstable_protocols = \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \ unstable/primary-selection/primary-selection-unstable-v1.xml \ + unstable/hdr-metadata/hdr-metadata-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/hdr-metadata/README b/unstable/hdr-metadata/README new file mode 100644 index 000..5a53ac3 --- /dev/null +++ b/unstable/hdr-metadata/README @@ -0,0 +1,4 @@ +HDR metadata protocol + +Maintainers: +Harish Krupo diff --git a/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml b/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml new file mode 100644 index 000..2553e1b --- /dev/null +++ b/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml @@ -0,0 +1,115 @@ + + + + +Copyright © 2019 Intel + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + The global interface used to instantiate a HDR surface from a wl_surface. + The extended interface will allow setting the hdr metadata including + mastering display properties, content light level and the EOTF to the + surface. + + + + + Informs the server that the client will not be using this + protocol object anymore. This does not affect any other objects, + zwp_hdr_surface_v1 objects included. + + + + + + + + + + Create an interface extension for the given wl_surface. This request + raises the HDR_SURFACE_EXISTS error if a zwp_hdr_surface_v1 is already + associated with the wl_surface. + + + + + + + + + + + An extension interface to the wl_surface object to set the HDR metadata + associated with the surface. + + + + + + + + + + Set the HDR metadata for the associated wl_surface. The HDR metadata + state is double buffered and will be applied on the next + wl_surface::commit. + + + + + + + + + + + + + + + + + + Set the eotf curve for the associated wl_surface. The eotf of the + surface state is double buffered and will be applied on the next + wl_surface::commit. + + + + + + + Destroying this object, destroys the HDR metadata associated with the + surface and the surface will be considered as an SDR surface from the + next wl_surface::commit. + + + + + -- 2.20.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[v2 0/2] Temporary protocols for HDR
This patch set adds two provisional protocols which would be utilized by our HDR stack which is published at [1]. A unified color management and HDR protocol is currently being discussed here [2] and is expected to supercede this patchset. Thank you Regards Harish Krupo [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/124 [2] https://lists.freedesktop.org/archives/wayland-devel/2019-March/040217.html Harish Krupo (1): hdr-metadata: Add protocol for static HDR metadata Ville Syrjälä (1): colorspace: Add protocol for setting surface's colorspace Makefile.am | 2 + unstable/colorspace/README| 4 + .../colorspace/colorspace-unstable-v1.xml | 79 unstable/hdr-metadata/README | 4 + .../hdr-metadata/hdr-metadata-unstable-v1.xml | 115 ++ 5 files changed, 204 insertions(+) create mode 100644 unstable/colorspace/README create mode 100644 unstable/colorspace/colorspace-unstable-v1.xml create mode 100644 unstable/hdr-metadata/README create mode 100644 unstable/hdr-metadata/hdr-metadata-unstable-v1.xml -- 2.20.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[v2 2/2] colorspace: Add protocol for setting surface's colorspace
From: Ville Syrjälä v2: Add description for the set request. Signed-off-by: Ville Syrjälä Signed-off-by: Harish Krupo --- Makefile.am | 1 + unstable/colorspace/README| 4 + .../colorspace/colorspace-unstable-v1.xml | 79 +++ 3 files changed, 84 insertions(+) create mode 100644 unstable/colorspace/README create mode 100644 unstable/colorspace/colorspace-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 8e70a9f..661e992 100644 --- a/Makefile.am +++ b/Makefile.am @@ -24,6 +24,7 @@ unstable_protocols = \ unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \ unstable/primary-selection/primary-selection-unstable-v1.xml \ unstable/hdr-metadata/hdr-metadata-unstable-v1.xml \ + unstable/colorspace/colorspace-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/colorspace/README b/unstable/colorspace/README new file mode 100644 index 000..6fa751a --- /dev/null +++ b/unstable/colorspace/README @@ -0,0 +1,4 @@ +Colorspace protocol + +Maintainers: +Ville Syrjälä diff --git a/unstable/colorspace/colorspace-unstable-v1.xml b/unstable/colorspace/colorspace-unstable-v1.xml new file mode 100644 index 000..73309a1 --- /dev/null +++ b/unstable/colorspace/colorspace-unstable-v1.xml @@ -0,0 +1,79 @@ + + + + +Copyright © 2019 Intel + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + This interface allows the client to set the color space of a surface. + + + + + + + + + + + + + + + + + + + + + Deleting this object does not affect the surfaces' colorspace set using + this interface. + + + + + + The colorspace set for the surface is double buffered and will be applied + on the next wl_surface::commit + + + + + + + -- 2.20.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 1/2] hdr-metadata: Add protocol for static HDR metadata
Hi Simon, Thanks for the comments. Please find my comments inline. Simon Ser writes: > Hi, > > Here are a few comments, from a protocol design perspective only. > > On Monday, March 11, 2019 8:36 PM, Harish Krupo > wrote: >> Signed-off-by: Harish Krupo >> --- >> Makefile.am | 1 + >> unstable/hdr-metadata/README | 4 + >> .../hdr-metadata/hdr-metadata-unstable-v1.xml | 104 ++ >> 3 files changed, 109 insertions(+) >> create mode 100644 unstable/hdr-metadata/README >> create mode 100644 unstable/hdr-metadata/hdr-metadata-unstable-v1.xml >> >> diff --git a/Makefile.am b/Makefile.am >> index 345ae6a..8e70a9f 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -23,6 +23,7 @@ unstable_protocols = >> \ >> unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ >> >> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml >> \ >> unstable/primary-selection/primary-selection-unstable-v1.xml >> \ >> +unstable/hdr-metadata/hdr-metadata-unstable-v1.xml >> \ >> $(NULL) >> >> stable_protocols = >> \ >> diff --git a/unstable/hdr-metadata/README b/unstable/hdr-metadata/README >> new file mode 100644 >> index 000..5a53ac3 >> --- /dev/null >> +++ b/unstable/hdr-metadata/README >> @@ -0,0 +1,4 @@ >> +HDR metadata protocol >> + >> +Maintainers: >> +Harish Krupo >> diff --git a/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml >> b/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml >> new file mode 100644 >> index 000..9c77fc9 >> --- /dev/null >> +++ b/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml >> @@ -0,0 +1,104 @@ >> + >> + >> + >> + >> +Copyright © 2018 Intel >> + >> +Permission is hereby granted, free of charge, to any person obtaining a >> +copy of this software and associated documentation files (the >> "Software"), >> +to deal in the Software without restriction, including without >> limitation >> +the rights to use, copy, modify, merge, publish, distribute, sublicense, >> +and/or sell copies of the Software, and to permit persons to whom the >> +Software is furnished to do so, subject to the following conditions: >> + >> +The above copyright notice and this permission notice (including the >> next >> +paragraph) shall be included in all copies or substantial portions of >> the >> +Software. >> + >> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS >> OR >> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL >> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR >> OTHER >> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER >> +DEALINGS IN THE SOFTWARE. >> + >> + >> + >> + >> + The global interface used to instantiate a hdr surface from a >> wl_surface. > > Style nit: "hdr" could be uppercase for consistency (it's an abbreviation). Yes, sure. > >> + The extended interface will allow setting the hdr metadata including >> + mastering display properties, content light level and the EOTF to the >> + surface. >> + >> + >> + >> + > > Style nit: "summary" properties are not capitalized. > Okay. >> +Informs the server that the client will not be using this >> +protocol object anymore. This does not affect any other objects, >> +zwp_hdr_surface_v1 objects included. >> + >> + >> + >> + >> + > + summary="the surface already has a hdr surface associated"/> >> + >> + >> + >> + >> +Create an interface extension for the given wl_surface. This request >> +raises the HDR_SURFACE_EXISTS error if a zwp_hdr_surface_v1 is already >> +associated with the wl_surface. >> + >> + > + summary="the new hdr surface interface id"/> >> + > + summ
[PATCH 2/2] colorspace: Add protocol for setting surface's colorspace
From: Ville Syrjälä Signed-off-by: Ville Syrjälä Signed-off-by: Harish Krupo --- Makefile.am | 1 + unstable/colorspace/README| 4 + .../colorspace/colorspace-unstable-v1.xml | 73 +++ 3 files changed, 78 insertions(+) create mode 100644 unstable/colorspace/README create mode 100644 unstable/colorspace/colorspace-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 8e70a9f..661e992 100644 --- a/Makefile.am +++ b/Makefile.am @@ -24,6 +24,7 @@ unstable_protocols = \ unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \ unstable/primary-selection/primary-selection-unstable-v1.xml \ unstable/hdr-metadata/hdr-metadata-unstable-v1.xml \ + unstable/colorspace/colorspace-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/colorspace/README b/unstable/colorspace/README new file mode 100644 index 000..6fa751a --- /dev/null +++ b/unstable/colorspace/README @@ -0,0 +1,4 @@ +Colorspace protocol + +Maintainers: +Ville Syrjälä diff --git a/unstable/colorspace/colorspace-unstable-v1.xml b/unstable/colorspace/colorspace-unstable-v1.xml new file mode 100644 index 000..4265a32 --- /dev/null +++ b/unstable/colorspace/colorspace-unstable-v1.xml @@ -0,0 +1,73 @@ + + + + +Copyright © 2018 Intel + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.20.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] hdr-metadata: Add protocol for static HDR metadata
Signed-off-by: Harish Krupo --- Makefile.am | 1 + unstable/hdr-metadata/README | 4 + .../hdr-metadata/hdr-metadata-unstable-v1.xml | 104 ++ 3 files changed, 109 insertions(+) create mode 100644 unstable/hdr-metadata/README create mode 100644 unstable/hdr-metadata/hdr-metadata-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 345ae6a..8e70a9f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -23,6 +23,7 @@ unstable_protocols = \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \ unstable/primary-selection/primary-selection-unstable-v1.xml \ + unstable/hdr-metadata/hdr-metadata-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/hdr-metadata/README b/unstable/hdr-metadata/README new file mode 100644 index 000..5a53ac3 --- /dev/null +++ b/unstable/hdr-metadata/README @@ -0,0 +1,4 @@ +HDR metadata protocol + +Maintainers: +Harish Krupo diff --git a/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml b/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml new file mode 100644 index 000..9c77fc9 --- /dev/null +++ b/unstable/hdr-metadata/hdr-metadata-unstable-v1.xml @@ -0,0 +1,104 @@ + + + + +Copyright © 2018 Intel + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + + + The global interface used to instantiate a hdr surface from a wl_surface. + The extended interface will allow setting the hdr metadata including + mastering display properties, content light level and the EOTF to the + surface. + + + + + Informs the server that the client will not be using this + protocol object anymore. This does not affect any other objects, + zwp_hdr_surface_v1 objects included. + + + + + + + + + + Create an interface extension for the given wl_surface. This request + raises the HDR_SURFACE_EXISTS error if a zwp_hdr_surface_v1 is already + associated with the wl_surface. + + + + + + + + + + + An extension interface to the wl_surface object to set the HDR metadata + associated with the surface. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- 2.20.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 0/2] [DO NOT MERGE] Temporary protocols for HDR
This patch set adds two placeholder protocols which would be utilized by our HDR stack which is published at [1]. A unified color management and HDR protocol is being discussed here [2] Thank you Regards Harish Krupo [1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/124 [2] https://lists.freedesktop.org/archives/wayland-devel/2019-March/040217.html Harish Krupo (1): hdr-metadata: Add protocol for static HDR metadata Ville Syrjälä (1): colorspace: Add protocol for setting surface's colorspace Makefile.am | 2 + unstable/colorspace/README| 4 + .../colorspace/colorspace-unstable-v1.xml | 73 unstable/hdr-metadata/README | 4 + .../hdr-metadata/hdr-metadata-unstable-v1.xml | 104 ++ 5 files changed, 187 insertions(+) create mode 100644 unstable/colorspace/README create mode 100644 unstable/colorspace/colorspace-unstable-v1.xml create mode 100644 unstable/hdr-metadata/README create mode 100644 unstable/hdr-metadata/hdr-metadata-unstable-v1.xml -- 2.20.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH] unstable: add HDR Mastering Meta-data Protocol
> From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Friday, March 1, 2019 7:49 PM > To: Nautiyal, Ankit K > Cc: wayland-devel@lists.freedesktop.org; sebast...@sebastianwick.net; > Sharma, Shashank ; e.bur...@gmail.com; > niels_...@salscheider-online.de; Kps, Harish Krupo > > Subject: Re: [PATCH] unstable: add HDR Mastering Meta-data Protocol > > On Fri, 1 Mar 2019 14:40:16 +0530 > "Nautiyal, Ankit K" wrote: > > > Hi Pekka, > > > > Thanks for the comments and suggestions. > > > > Please my responses inline: > > > > On 2/28/2019 7:51 PM, Pekka Paalanen wrote: > > > On Wed, 27 Feb 2019 10:27:16 +0530 > > > "Nautiyal, Ankit K" wrote: > > > > > >> From: Ankit Nautiyal > > >> > > >> This protcol enables a client to send the hdr meta-data: > > >> MAX-CLL, MAX-FALL, Max Luminance and Min Luminance as defined by > > >> SMPTE ST.2086. > > >> The clients get these values for an HDR video, encoded for a video > > >> stream/file. MAX-CLL (Maximum Content Light Level) tells the > > >> brightest pixel in the entire stream/file in nits. > > >> MAX-FALL (Maximum Frame Average Light Level) tells the highest > > >> frame average brightness in nits for a single frame. Max and Min > > >> Luminance tells the max/min Luminance for the mastering display. > > >> These values give an idea of the brightness of the video which can > > >> be used by displays, so that they can adjust themselves for a > > >> better viewing experience. > > >> > > >> The protocol depends on the Color Management Protocol which is > > >> still under review. There are couple of propsed protocols by Neils > > >> Ole [1], and Sebastian Wick [2], which allow a client to select a > > >> color-space for a surface, via ICC color profile files. > > >> The client is expected to set the color space using the icc files > > >> and the color-management protocol. > > >> > > >> [1]https://patchwork.freedesktop.org/patch/134570/ > > >> [2]https://patchwork.freedesktop.org/patch/286062/ > > >> > > >> Co-authored-by: Harish Krupo > > >> Signed-off-by: Ankit Nautiyal > > > >> diff --git > > >> a/unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v > > >> 1.xml > > >> b/unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v > > >> 1.xml > > >> new file mode 100644 > > >> index 000..aeddf39 > > >> --- /dev/null > > >> +++ b/unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstab > > >> +++ le-v1.xml > > > Could it be named hdr-mastering rather than hdr-mastering-metadata? > > > Shorter C function names wouldn't hurt. > > Yes I guess, thanks for the suggestion, or perhaps "hdr-metadata" ? > > Hi Ankit, > > to me, the word "metadata" is the redundant one. "HDR" is significant, > "mastering" is probably significant as well, but since we are talking about > Wayland, half of the protocol is essentially metadata. > > But "hdr-metadata" is not bad either. > > Then we have hdr_surface.set_hdr_mastering_metadata. That could be simply > hdr_surface.set_metadata... or hdr_surface.set_luminance since all the > arguments are about luminance somehow. > > Does mastering metadata include more than just luminance parameters? > The primaries and white point maybe? > Yes, it does. It contains the primaries and white point along with luminance of the display used for mastering the content. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] unstable: add HDR Mastering Meta-data Protocol
Hi Pekka, I have some comments to add to Ankit's. Please find them inline. Nautiyal, Ankit K writes: > Hi Pekka, > > Thanks for the comments and suggestions. > > Please my responses inline: > > On 2/28/2019 7:51 PM, Pekka Paalanen wrote: >> On Wed, 27 Feb 2019 10:27:16 +0530 >> "Nautiyal, Ankit K" wrote: >> >>> From: Ankit Nautiyal >>> >>> This protcol enables a client to send the hdr meta-data: >>> MAX-CLL, MAX-FALL, Max Luminance and Min Luminance as defined by >>> SMPTE ST.2086. >>> The clients get these values for an HDR video, encoded for a video >>> stream/file. MAX-CLL (Maximum Content Light Level) tells the brightest >>> pixel in the entire stream/file in nits. >>> MAX-FALL (Maximum Frame Average Light Level) tells the highest frame >>> average brightness in nits for a single frame. Max and Min Luminance >>> tells the max/min Luminance for the mastering display. >>> These values give an idea of the brightness of the video which can be >>> used by displays, so that they can adjust themselves for a better >>> viewing experience. >>> >>> The protocol depends on the Color Management Protocol which is still >>> under review. There are couple of propsed protocols by Neils Ole [1], >>> and Sebastian Wick [2], which allow a client to select a color-space >>> for a surface, via ICC color profile files. >>> The client is expected to set the color space using the icc files and >>> the color-management protocol. >>> I believe this part should be removed as the hdr_surface object wraps over the wl_surface and doesn't interact with colorspace objects. More on this below. >>> [1]https://patchwork.freedesktop.org/patch/134570/ >>> [2]https://patchwork.freedesktop.org/patch/286062/ >>> >>> Co-authored-by: Harish Krupo >>> Signed-off-by: Ankit Nautiyal >> Hi Ankit, >> >> thanks for working on this, comments inline. >> >> I do wonder if this should just be baked into a color management >> extension directly. More on that below. > > We had this in mind initially with this line of thought in couple of early > interactions with Niels and Sebastian. > Later I had a discussion in #wayland with Sebastian, and it seemed that the > brightness values should be handled separately, > as these do not directly come under ICC profiles as far as I understand. > As we know HDR comprises of : > * Transfer functions > * Color primaries > * Mastering meta-data : MAX_CLL, MAX_FALL etc. > Out of these, the first two, can be handled by color-manager and would not > change often. > HDR mastering meta-data, as is discussed is coming from the video stream, and > with the dynamic HDR mastering metadata, > these brightness/luminance values might change frame by frame. > So it makes sense to have a separate protocol for this, where a client can > tell > the compositor about the color-space once with the color-manager protocol, > and these luminance values, can be sent to the compositor as per the video > frames. > Agreed. The two protocols do not interact with each other and can be used independently. >>> --- >>> Makefile.am| 1 + >>> unstable/hdr-mastering-metadata/README | 5 ++ >>> .../hdr-mastering-metadata-unstable-v1.xml | 95 >>> ++ >>> 3 files changed, 101 insertions(+) >>> create mode 100644 unstable/hdr-mastering-metadata/README >>> create mode 100644 >>> unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v1.xml >>> >>> diff --git a/Makefile.am b/Makefile.am >>> index 345ae6a..c097080 100644 >>> --- a/Makefile.am >>> +++ b/Makefile.am >>> @@ -23,6 +23,7 @@ unstable_protocols = >>> \ >>> unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ >>> >>> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml >>> \ >>> unstable/primary-selection/primary-selection-unstable-v1.xml >>> \ >>> + unstable/hdr-mastering-metadata/hdr-mastering-metadata-unstable-v1.xml >>> \ >>> $(NULL) >>> stable_protocols = >>> \ >>> diff --git a/unstable/hdr-mastering-metadata/README >>> b/unstable/hdr-mastering-metadata/README >>> new file mode 100644 >>> index 000..b567860 >>> --- /dev/null >&
Re: [RFC] Weston GL shader compilation re-design
Hi Pekka, Thank you for the comments. I wIll start implementing the shader building. Pekka Paalanen writes: > On Wed, 23 Jan 2019 11:32:34 +0530 > Harish Krupo wrote: > >> Hi, >> >> This is in continuation to the discussion in the mail chain here [1]. We >> are currently working on enabling HDR rendering support in the >> gl-renderer. HDR support requires color space conversion (709->2020 or >> other way around) and Tone Mapping, for which, we need to execute the >> following steps in the shader: >> * Degamma (to linearize the buffer) >> * Color space conversion (BT2020 -> BT709...) >> * Tone mapping (SDR -> HDR, HDR -> SDR, HDR -> HDR conversion) >> * Gamma: Apply gamma/transfer function for the display (PQ/HLG...) >> >> We are currently targeting the DCI-P3, SRGB and 2084 color spaces. One >> way to implement it would be to create multiple sets of shaders for each >> degamma/gamma combination. Like the one done by Ville in his POC [2]. >> This solution was a POC, and isn't scalable when we need to support >> multiple color spaces. I would like to propose 2 different solutions: >> >> Proposal 1: >> * Each of the shaders (gamma/degamma/main/tone mapping) would be >> independent strings. >> * When the view needs to be rendered, renderer will generate a set of >> requirements like need degamma PQ curve, need tone mapping, need gamma >> SRGB curve and so on. >> * These requirements (NEED_GAMMA_PQ...) would be bit fields and will be >> OR'd to create the total requirements. >> * This total requirement would be used to stitch the required shaders to >> compile a program. The total requirements integer will also be used as >> a key to store that program in a hashmap for re-use. >> >> Proposal 2: >> We could go for multi pass rendering, where each of the steps (gamma, >> csc, tone mappping, degamma) will be applied in different passes. Each >> pass would bind an fbo and call draw elements with the corresponding >> shader. This would not be as efficient but is another approach. >> >> Please comment on the approaches and do suggest if there is a better >> one. > > Hi Harish, > > choosing between multipass rendering and more complicated shader > building, I would definitely take the more complicated shader building > first. If the use case is video playback, then the clients will be > updating very often and the frames they produce will likely ever be > composited just once. Using multipass with intermediate buffers would > just blow up the memory bandwidth usage. > > Later, if someone wants to optimize things more for rarely updating > surfaces, they could implement an image cache for some stages of the > pixel conversions. > > Precision is another benefit of a complicated shader that does > everything in one go: the intermediate values in the shader can be > stored in GPU registers at high precision. Achieving the same precision > with multipass would cost a huge amount of memory. Memory saving is a > big reason why one almost always store images with gamma applied, even > in memory rather than just files. > > Btw. when enhancing the fragment shader mechanics, I think we could > rely more on the GLSL compilers than we do today. What I mean by that > is that we could have the shader's main call functions that do each of > the conversion steps to the pixel values, and then when concatenating > the shader string, we pick the appropriate function implementations into > it. No-op or pass-through functions ideally shouldn't produce any worse > code than manually not calling them. IOW, go with a more function than > macro oriented design in assembling the complete frament shader string. > > I think code maintainability and clarity should be the foremost goal, > but avoiding any serious performance issues. Fine-tuning the shader > performance, e.g. investigating a single "megashader" vs. multiple > specific shaders can be left out for now. Unless someone has solid > knowledge about what would be best already? > > Of course, we should stick to GL ES 2.0 capabilities if possible, but > we could also consider requiring GL ES 3.0 if that would seem too > useful to ignore. > > > Thanks, > pq > >> >> [1] >> https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html >> >> [2] >> https://github.com/vsyrjala/weston/blob/hdr_poc/libweston/gl-renderer.c#L257 Regards Harish Krupo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC] Weston GL shader compilation re-design
Hi, This is in continuation to the discussion in the mail chain here [1]. We are currently working on enabling HDR rendering support in the gl-renderer. HDR support requires color space conversion (709->2020 or other way around) and Tone Mapping, for which, we need to execute the following steps in the shader: * Degamma (to linearize the buffer) * Color space conversion (BT2020 -> BT709...) * Tone mapping (SDR -> HDR, HDR -> SDR, HDR -> HDR conversion) * Gamma: Apply gamma/transfer function for the display (PQ/HLG...) We are currently targeting the DCI-P3, SRGB and 2084 color spaces. One way to implement it would be to create multiple sets of shaders for each degamma/gamma combination. Like the one done by Ville in his POC [2]. This solution was a POC, and isn't scalable when we need to support multiple color spaces. I would like to propose 2 different solutions: Proposal 1: * Each of the shaders (gamma/degamma/main/tone mapping) would be independent strings. * When the view needs to be rendered, renderer will generate a set of requirements like need degamma PQ curve, need tone mapping, need gamma SRGB curve and so on. * These requirements (NEED_GAMMA_PQ...) would be bit fields and will be OR'd to create the total requirements. * This total requirement would be used to stitch the required shaders to compile a program. The total requirements integer will also be used as a key to store that program in a hashmap for re-use. Proposal 2: We could go for multi pass rendering, where each of the steps (gamma, csc, tone mappping, degamma) will be applied in different passes. Each pass would bind an fbo and call draw elements with the corresponding shader. This would not be as efficient but is another approach. Please comment on the approaches and do suggest if there is a better one. Thank you Regards Harish Krupo [1] https://lists.freedesktop.org/archives/wayland-devel/2019-January/039809.html [2] https://github.com/vsyrjala/weston/blob/hdr_poc/libweston/gl-renderer.c#L257 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: HDR support in Wayland/Weston
Hi Arnaud, Thank you for the comments, please find mine inline. Arnaud Vrac writes: > On Thu, Jan 17, 2019 at 4:26 AM Sharma, Shashank > wrote: >> >> > The proposal is missing many important bits like negotiation of the >> > supported output features with the client, double buffering the new >> > colorspace related surface properties, using more of the hardware >> > capabilities, performance issues, etc... >> >> > Also, the added protocols are >> > probably too simple as far as color management is concerned. >> Agree, there are two reasons for that: >> - This proposal is a very high level design focusing the changes >> required only to drive HDR video playback, in the real implementation, >> you would see many of those mentioned. I think its too early to talk >> about performance as we are still in design stage. >> - As we have been discussing in parallel threads, HDR is too big a >> feature, and we don't want to add too much of code in a single shot, and >> create unwanted regressions and maintenance nightmares, rather, the aim >> is to create small, modular, scalable, easy to review and test kind of >> feature set, which might be targeting a very specific area, and >> gradually complete this feature. >> >> But I would like to hear more about double buffering of the new >> colorspace related surface properties if you can please elaborate more ? > > The colorspace related properties should be applied atomically when > commiting the wl_surface. This is not done in Ville's patches, so > there might be some rendering glitches when changing the colorspace > while the surface is displayed. > Yes, both the colospace property and the hdr metadata for a surface are double buffered and are applied only on wl_surface.commit. This should be clear once we start posting our patches. Thank you Regards Harish Krupo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Use-case for CTRC background color?
Hi Pekka, Thanks for the in-depth and descriptive reply. I will begin understanding the code and start making changes. I will revert back to this mail if I have doubts. :) Thank you Regards Harish Krupo Pekka Paalanen writes: > On Fri, 16 Nov 2018 09:19:17 +0530 > Harish Krupo wrote: > >> Hi, >> >> This patch [1] introduces the background crtc color property. This >> property is available on some display controlers and allows setting a >> non-black colors for pixels not covered by any plane (or pixels covered >> by the transparent regions of higher planes). I would like to implement >> a userspace consumer of this propery in weston. >> The primary use case for this property is for compositors to set the >> background color. I am planning on implementing it as follows: >> * The desktop client would bind to the weston-desktop-shell protocol. >> * The weston-desktop-shell would have a wrapper for the wl_output >> object. >> * The client would create a wrapper for wl_output (maybe called >> weston_desktop_shell_output). >> * This output interface will have an event to advertise its capability >> to set the background color directly. >> * Once the capability is found and if the client wishes to set the >> background color, it would use the set_background_color request in the >> weston_desktop_shell_ouput interface to set the color by providing the >> r,g,b primaries. >> >> I have not completely thought this through, so I am sure this is >> incomplete and will require modification. I would like to know your >> comments and suggestions on the above method (or even if we could use >> this property differently) before I begin the implementation. > > Hi, > > the problem is that Weston will always have an opaque framebuffer on > the primary plane, and that primary plane will always cover the whole > CRTC area, which means that there is never a chance for a CRTC > background color to show through. You will have to change that by > allowing the primary plane to be smaller that the CRTC area or to be > omitted completely. I would ignore the case of the primary plane > framebuffer having a non-opaque alpha channel at start, because if the > hardware supports that it will be easy to make it work, unlike letting > the primary plane be smaller or omitted which is where the real > benefits are (memory bandwidth savings). > > How to make use of and how to control the CRTC background color is a > good question. Just like any other detail of display, I think there > should not be an explicit protocol, even private one, to set the color. > A public protocol would be fought over by multiple clients, and a > private protocol would only be useful for the single helper client (e.g. > weston-desktop-shell) while leaving other use cases unaccounted for > (fullscreen video playback with black or other colored bars). > > Therefore I think the right approach to control the CRTC background > color is to integrate it as part of the scenegraph, and recognize it > from the scenegraph to be used automatically, just like we use overlay > planes today. > > The most optimal way for a video player to add black (or other colored) > bars around a fullscreen video is to make a single-color surface behind > the video surface. The player should use the sub-surface protocol to > layer the surfaces. The optimal way to create a single-color surface of > an arbitrary size is to use a 1x1 pixel wl_shm buffer scaled up to the > needed size with wl_viewport. > > Weston internally has a concept of a solid-color surface, but those can > only be created internally, never by clients. It would be good to have > Weston recognize client surfaces with a 1x1 buffer and turn those > internally into solid-color surfaces. Then, the scenegraph analysis in > the DRM-backend can attempt to promote solid-color surfaces into a CRTC > background color setting. Once this works, it no longer matters how > many surfaces are on an output or which client created them; if the > scenegraph implies that CRTC background color can be used, then it will > be used and it will always be correct. > > weston-desktop-shell helper client can be modified to use single-color > surfaces itself, which will make the compositor use the CRTC background > color automatically whenever the hardware supports it. That way > weston-desktop-shell does not need to worry about whether the hardware > or compositor supports it, and it can always use the same logic to set > up the desktop background. If the wallpaper is smaller than the output, > then this will result in memory savings regardless of whether the CRTC > background color is supported. This change could actual
Re: Use-case for CTRC background color?
Ucan, Emre (ADITG/ESB) writes: > Hi Harish, > > Then, this would only work for desktop-shell. Furthermore, I cannot set > different background colors to different outputs. > > Also my suggestion is simpler to implement. > Yes, that indeed is easier to implement. Unfortunately, the desktop shell would fall back to setting 0x even if we were to comment out background-image and background-color in the config. This would obscure our color because the background-color set by the desktop shell would fill the complete display resolution on a plane. I see 2 options: * We can make desktop-shell.c skip the setting of the background color if a color is provided for an output. Unfortunately, the desktop shell sets the color for background and not per output. * The other option would be that we ignore desktop shell's background when the color is provided in the output. But here we cannot identify if the client set a wallpaper or a plain color. With the above issues, I don't think we can go for this implementation. Please correct me if I have got something wrong. Thank you Regards Harish Krupo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Use-case for CTRC background color?
Hi Emre, Thanks for replying. Ucan, Emre (ADITG/ESB) writes: > Hi, > > Clients should not control a property of a wl_output directly. > > You can add a new property to the weston-config for output section, so that > weston can enable a specific color for an output at startup. Sorry, I should have been specific. The user would set the color here [1]. The desktop client would then check if the output (output wrapper) has advertised the background color capability. If so, it would then set the color using a different request as compared the the set_background request which already exists in weston-desktop-shell. This interface would take R, G, B colors instead of a buffer. Thank you Regards Harish Krupo [1] https://gitlab.freedesktop.org/wayland/weston/blob/master/weston.ini.in#L10 >> -Original Message- >> From: wayland-devel On >> Behalf Of Harish Krupo >> Sent: Freitag, 16. November 2018 04:57 >> To: wayland-devel@lists.freedesktop.org >> Cc: pekka.paala...@collabora.co.uk; dani...@collabora.com >> Subject: Use-case for CTRC background color? >> >> Hi, >> >> This patch [1] introduces the background crtc color property. This >> property is available on some display controlers and allows setting a >> non-black colors for pixels not covered by any plane (or pixels covered >> by the transparent regions of higher planes). I would like to implement >> a userspace consumer of this propery in weston. >> The primary use case for this property is for compositors to set the >> background color. I am planning on implementing it as follows: >> * The desktop client would bind to the weston-desktop-shell protocol. >> * The weston-desktop-shell would have a wrapper for the wl_output >> object. >> * The client would create a wrapper for wl_output (maybe called >> weston_desktop_shell_output). >> * This output interface will have an event to advertise its capability >> to set the background color directly. >> * Once the capability is found and if the client wishes to set the >> background color, it would use the set_background_color request in the >> weston_desktop_shell_ouput interface to set the color by providing the >> r,g,b primaries. >> >> I have not completely thought this through, so I am sure this is >> incomplete and will require modification. I would like to know your >> comments and suggestions on the above method (or even if we could use >> this property differently) before I begin the implementation. >> >> Thank you >> Regards >> Harish Krupo >> >> [1] https://patchwork.freedesktop.org/series/50834/ >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Use-case for CTRC background color?
Hi, This patch [1] introduces the background crtc color property. This property is available on some display controlers and allows setting a non-black colors for pixels not covered by any plane (or pixels covered by the transparent regions of higher planes). I would like to implement a userspace consumer of this propery in weston. The primary use case for this property is for compositors to set the background color. I am planning on implementing it as follows: * The desktop client would bind to the weston-desktop-shell protocol. * The weston-desktop-shell would have a wrapper for the wl_output object. * The client would create a wrapper for wl_output (maybe called weston_desktop_shell_output). * This output interface will have an event to advertise its capability to set the background color directly. * Once the capability is found and if the client wishes to set the background color, it would use the set_background_color request in the weston_desktop_shell_ouput interface to set the color by providing the r,g,b primaries. I have not completely thought this through, so I am sure this is incomplete and will require modification. I would like to know your comments and suggestions on the above method (or even if we could use this property differently) before I begin the implementation. Thank you Regards Harish Krupo [1] https://patchwork.freedesktop.org/series/50834/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
