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
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: A
+ 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 c
Parentheses: 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:
>&
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
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.
>
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 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 co
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
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 th
>
>> +
>> +
>> +
>
> 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: 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
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
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
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
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
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
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
> 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 Krup
t;>> 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 doe
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
>>
roaches 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
___
w
>
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
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
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
___
way
ich 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
>> Beh
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
27 matches
Mail list logo
