Re: HDR support in Wayland/Weston
Hi Ole, I was going through the protocol you had proposed, and have some silly questions, please pardon my ignorance. From where can the client-applications get the ICC profile files? Does the client application manufacture it for a given color space and a standard template? Or the compositor needs to store .icc files for each of the color-spaces, which the clients can use. Also, are there already libraries that can be user to parse the .icc files? I can see some recommended by ICC, like SampleICC, Argyll etc, is there something which suits our case better? Regards, Ankit On 1/10/2019 9:31 PM, Niels Ole Salscheider wrote: Hello, on a first glance this sounds sensible. Would it work well with the last color management protocol proposal that I made or do you see issues there? We could add REC2020 as another predefined profile. https://lists.freedesktop.org/archives/wayland-devel/2017-January/032769.html I think the last proposal was mostly sane and usable for everybody, but there was not much interest afterwards. However, there was a lot of discussion with wishes from different sides that went into this. The relevant mailing list threads are the following, but you have to follow the discussion over the next months: https://lists.freedesktop.org/archives/wayland-devel/2016-November/031728.html https://lists.freedesktop.org/archives/wayland-devel/2014-March/013951.html Best regards, Ole Am Donnerstag, 10. Januar 2019, 16:02:18 CET schrieb Sharma, Shashank: Hello All, This mail is to propose a design for enabling HDR support in Wayland/Weston stack, using display engine capabilities, and get more feedback and input from community. Here are few points (you might already know these), about HDR framebuffers, videos and displays: - HDR content/buffers are composed in REC2020 colorspace, with bit depth 10/12/16 BPC. Some of the popular formats are P010,P012,P016. - HDR content come with their own Metadata to be applied to get the right luminance at the display device. - The metadata can be of two type 1. static 2. dynamic . For simplicity, this solution is focusing on static HDR only (HDR10 standard) - HDR content also provide its supported EOTF (electro optical transfer function) information, which is a curve (like SRGB gamma curve). One popular EOTF is PQ(ST2084). - HDR capable displays mention their EOTF and HDR metadata support information in EDID CEA-861-G blocks. - Normal SRGB buffers are composed in SRGB color space following REC709 specifications. - For accurate blending in display engines, we need to make sure following: - All the buffers are in same colorspace (Rec 709 or Rec 2020) - All the buffers are liner (gamma/EOTF removed) - All the buffers are tone mapped in same zone (HDR or SDR) Please refer to the block diagram below, which presents a simple case of a HDR P010 movie playback, with HDR buffers as video buffers, and SDR buffers as subtitles. The subsystem looks and works like this: - A client decodes the buffer (using FFMpeg for example) and gets the two buffers, one with video (HDR) and one subtitles (SDR) - Client passes following information to the compositor: - The actual buffers - Their colorspace infromation, BT2020 for HDR buffer, REC709 for SDR buffer (planning to add a new protocol extension for this) - The HDR metadata of the content (planning to add new protocol for this) - Compositors actions: - Reads the End display's HDR capabilities from display EDID. Assume its an HDR HDMI monitor. - Compositor tone maps every view's framebuffer to match tone of end display, applying a libVA filter. In this example: - The SDR subtitles frame will go through SDR to HDR tone mapping (called S2H) - The HDR video frame will go through HDR to HDR tone mapping (called H2H) if the HDR capabilities of monitor and content are different. - Now both the buffers and the monitor are in the same tone mapped range. - As the end display is HDR capable, and one of the content frame is HDR, the compositor will prepare all other planes for color space conversion (CSC) from REC709->REC2020 using plane CSC property. - As the CSC and blending should be done in liner space, compositor will also use plane level degamma to make the buffers linear. - These actions will make sure that, during blending: - All the buffers are in same colorspace (REC2020) - All the buffers are linear - All the buffers are tone mapped (HDR) - The plane level color properties patch, for DRM can be found here: https://patchwork.freedesktop.org/series/30875/ - Now, in order to re-apply the HDR curve, compositor will apply CRTC level gamma, so that the output buffer is non-linear again. - To pass the output HDR information to kernel, so that it can create and send AVI-info-frames to HDMI, compositor will set Connector HDR metadata property. - Code for the
Re: Upcoming release
Hi Emre, On Sat, 19 Jan 2019 at 20:39, Ucan, Emre (ADITG/ESB) wrote: > I would like to push XDG shell support for ivi-shell: > https://gitlab.freedesktop.org/wayland/weston/merge_requests/86 > > It would be great if you and other maintainers can ack and/or review this > merge request till beginning of February. If they are no major concerns, it > would be great to have it in this release. I've reviewed this now, and there are only some minor changes I can see need making. If Michael agrees with the suggested changes, I'm fine with either him making the changes and updating the MR, or if he has no time this week, I could just do it myself. I'd be really really glad to make ivi_application very deprecated. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Upcoming release
On 1/30/19 6:58 AM, Alexandros Frantzis wrote: > On Fri, Jan 25, 2019 at 10:05:47AM -0600, Derek Foreman wrote: >> On 1/18/19 4:20 PM, Derek Foreman wrote: >>> Hi all, >>> >>> It's been quite some time since our last weston release, and there's >>> been some discussion of getting the next one out in the January to March >>> timeframe (this would be the last release to have an autotools build, btw). >>> >>> Does anyone have objections to an early February freeze and a March >>> release? Anyone with large series near completion? >>> >>> Also, I'd like to float the idea of removing the fbdev backend for this >>> release (or the next). The bulk of the interesting features target the >>> drm backend, and it feels like fbdev can sometimes be a bit of a pain to >>> update when changes are required elsewhere. Any strong opinions either way? >> >> Ok, I've heard no complaints, and we really are overdue... >> >> There's been some reasonable pushback against dropping fbdev >> immediately, so let's leave that in for this release. >> >> As to the release schedule, maybe: >> February 1, Alpha >> February 15, Beta >> March 1, RC1 >> March 8 as a first potential final release date. >> >> Is this too soon to enter freeze? It's not a lot of warning. >> >> Wayland has had enough changes that I think another joint release makes >> sense. >> >> Thanks, >> Derek > > Hi Derek, > > it would be nice if we could also try to get the weston support for the > zwp_linux_explicit_synchronization_unstable_v1 protocol in the next > release, given that the protocol itself has landed since some time now > (wayland-protocols 1.17). > > The MR for the explicit sync implementation is at: > > https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 At this point I'm thinking at least a one week push on the proposed release schedule. Is that enough to get this one in? Thanks, Derek > Thanks, > Alexandros > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Upcoming release
On 1/30/19 6:19 AM, Pekka Paalanen wrote: > On Mon, 28 Jan 2019 12:13:12 +0200 > Pekka Paalanen wrote: > >> On Fri, 25 Jan 2019 10:05:47 -0600 >> Derek Foreman wrote: >> >>> On 1/18/19 4:20 PM, Derek Foreman wrote: Hi all, It's been quite some time since our last weston release, and there's been some discussion of getting the next one out in the January to March timeframe (this would be the last release to have an autotools build, btw). Does anyone have objections to an early February freeze and a March release? Anyone with large series near completion? Also, I'd like to float the idea of removing the fbdev backend for this release (or the next). The bulk of the interesting features target the drm backend, and it feels like fbdev can sometimes be a bit of a pain to update when changes are required elsewhere. Any strong opinions either way? >>> >>> Ok, I've heard no complaints, and we really are overdue... >>> >>> There's been some reasonable pushback against dropping fbdev >>> immediately, so let's leave that in for this release. >>> >>> As to the release schedule, maybe: >>> February 1, Alpha >>> February 15, Beta >>> March 1, RC1 >>> March 8 as a first potential final release date. >>> >>> Is this too soon to enter freeze? It's not a lot of warning. >>> >>> Wayland has had enough changes that I think another joint release makes >>> sense. >> >> Hi, >> >> here are my picks from the pending reviews. I don't mean that we should >> wait on them unless noted explicitly below. Thanks for putting this list together. >> Wayland: >> >> I reviewed https://patchwork.freedesktop.org/series/49379/ and it needs >> work. >> >> https://patchwork.freedesktop.org/series/38564/ is probably something I >> should look into to have in the alpha. > > That one landed. > >> >> Weston: >> >> https://gitlab.freedesktop.org/wayland/weston/merge_requests/66 is >> something I'd like to land, but it needs a small touch. >> >> https://gitlab.freedesktop.org/wayland/weston/merge_requests/62 is >> probably important enough, that I'd be willing to postpone the release >> until we get that in. Looks like it is very close. Jonas mentioned this one on IRC too. Looks like it's close enough to delay the release for, and I think everyone would really like to see it landed. >> Since Meson is a new thing, >> https://gitlab.freedesktop.org/wayland/weston/merge_requests/85 would >> probably be nice to decide on. >> >> Getting NEWS files would be cool too. This was just the first attempt >> that got useful feedback but I never had the time to take it further: >> https://patchwork.freedesktop.org/series/16218/ >> > > I took a look at the Weston changes since 5.0.0 release: > > - the exported symbols from weston executable have changed, backwards > incompatible, but this probably shouldn't count against libweston > major > > - struct weston_head gained a new member > > - struct weston_compositor gained new members > > - struct weston_surface gained a new member > > I guess these are reasons enough to bump the major to 6, right? > > Would have been interesting to release a 5.1.0, too bad. :-) Thanks for looking into this, as I wasn't sure yet what the new release would be called. :) Sounds like a 6 to me. We'll definitely be in a holding pattern until the xdg-shell (MR 62) stuff lands. Thanks, Derek > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Print NULL strings as "nil" in wl_closure_print
On Tue, 29 Jan 2019 22:00:40 +
Simon Ser wrote:
> Calling printf("%s", NULL) is undefined behaviour.
>
> Signed-off-by: Simon Ser
> ---
> src/connection.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/connection.c b/src/connection.c
> index f965210..474c97b 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -1278,7 +1278,10 @@ wl_closure_print(struct wl_closure *closure, struct
> wl_object *target, int send)
> wl_fixed_to_double(closure->args[i].f));
> break;
> case 's':
> - fprintf(stderr, "\"%s\"", closure->args[i].s);
> + if (closure->args[i].s)
> + fprintf(stderr, "\"%s\"", closure->args[i].s);
> + else
> + fprintf(stderr, "nil");
> break;
> case 'o':
> if (closure->args[i].o)
Pushed:
d325140..6afb152 master -> master
Thanks,
pq
pgp0h1TMrftWs.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Upcoming release
On Fri, Jan 25, 2019 at 10:05:47AM -0600, Derek Foreman wrote: > On 1/18/19 4:20 PM, Derek Foreman wrote: > > Hi all, > > > > It's been quite some time since our last weston release, and there's > > been some discussion of getting the next one out in the January to March > > timeframe (this would be the last release to have an autotools build, btw). > > > > Does anyone have objections to an early February freeze and a March > > release? Anyone with large series near completion? > > > > Also, I'd like to float the idea of removing the fbdev backend for this > > release (or the next). The bulk of the interesting features target the > > drm backend, and it feels like fbdev can sometimes be a bit of a pain to > > update when changes are required elsewhere. Any strong opinions either way? > > Ok, I've heard no complaints, and we really are overdue... > > There's been some reasonable pushback against dropping fbdev > immediately, so let's leave that in for this release. > > As to the release schedule, maybe: > February 1, Alpha > February 15, Beta > March 1, RC1 > March 8 as a first potential final release date. > > Is this too soon to enter freeze? It's not a lot of warning. > > Wayland has had enough changes that I think another joint release makes > sense. > > Thanks, > Derek Hi Derek, it would be nice if we could also try to get the weston support for the zwp_linux_explicit_synchronization_unstable_v1 protocol in the next release, given that the protocol itself has landed since some time now (wayland-protocols 1.17). The MR for the explicit sync implementation is at: https://gitlab.freedesktop.org/wayland/weston/merge_requests/32 Thanks, Alexandros ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Upcoming release
On Mon, 28 Jan 2019 12:13:12 +0200 Pekka Paalanen wrote: > On Fri, 25 Jan 2019 10:05:47 -0600 > Derek Foreman wrote: > > > On 1/18/19 4:20 PM, Derek Foreman wrote: > > > Hi all, > > > > > > It's been quite some time since our last weston release, and there's > > > been some discussion of getting the next one out in the January to March > > > timeframe (this would be the last release to have an autotools build, > > > btw). > > > > > > Does anyone have objections to an early February freeze and a March > > > release? Anyone with large series near completion? > > > > > > Also, I'd like to float the idea of removing the fbdev backend for this > > > release (or the next). The bulk of the interesting features target the > > > drm backend, and it feels like fbdev can sometimes be a bit of a pain to > > > update when changes are required elsewhere. Any strong opinions either > > > way? > > > > Ok, I've heard no complaints, and we really are overdue... > > > > There's been some reasonable pushback against dropping fbdev > > immediately, so let's leave that in for this release. > > > > As to the release schedule, maybe: > > February 1, Alpha > > February 15, Beta > > March 1, RC1 > > March 8 as a first potential final release date. > > > > Is this too soon to enter freeze? It's not a lot of warning. > > > > Wayland has had enough changes that I think another joint release makes > > sense. > > Hi, > > here are my picks from the pending reviews. I don't mean that we should > wait on them unless noted explicitly below. > > Wayland: > > I reviewed https://patchwork.freedesktop.org/series/49379/ and it needs > work. > > https://patchwork.freedesktop.org/series/38564/ is probably something I > should look into to have in the alpha. That one landed. > > Weston: > > https://gitlab.freedesktop.org/wayland/weston/merge_requests/66 is > something I'd like to land, but it needs a small touch. > > https://gitlab.freedesktop.org/wayland/weston/merge_requests/62 is > probably important enough, that I'd be willing to postpone the release > until we get that in. Looks like it is very close. > > Since Meson is a new thing, > https://gitlab.freedesktop.org/wayland/weston/merge_requests/85 would > probably be nice to decide on. > > Getting NEWS files would be cool too. This was just the first attempt > that got useful feedback but I never had the time to take it further: > https://patchwork.freedesktop.org/series/16218/ > I took a look at the Weston changes since 5.0.0 release: - the exported symbols from weston executable have changed, backwards incompatible, but this probably shouldn't count against libweston major - struct weston_head gained a new member - struct weston_compositor gained new members - struct weston_surface gained a new member I guess these are reasons enough to bump the major to 6, right? Would have been interesting to release a 5.1.0, too bad. :-) Thanks, pq pgphnvDTqiWDv.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC weston] libinput: support high-resolution scroll wheels
On Wed, 30 Jan 2019 09:47:39 +1000
Peter Hutterer wrote:
> On Tue, Jan 29, 2019 at 03:36:41PM +0200, Pekka Paalanen wrote:
> > On Tue, 29 Jan 2019 16:57:34 +1000
> > Peter Hutterer wrote:
> >
> > > The new API returns scroll wheels as fractions of 120.
> > >
> > > Signed-off-by: Peter Hutterer
> > > ---
> > > Turns out it's not the most complicated patch...
> > >
> > > This is an RFC only because libinput hasn't been released yet, and it's
> > > waiting on the kernel release anyway. Given the expected delay, I hope
> > > autotools is removed by the time this becomes a mergeable.
> > >
> > > libweston/libinput-device.c | 6 ++
> > > meson.build | 9 +
> > > 2 files changed, 15 insertions(+)
> > >
> > > diff --git a/libweston/libinput-device.c b/libweston/libinput-device.c
> > > index e25df144..e028d246 100644
> > > --- a/libweston/libinput-device.c
> > > +++ b/libweston/libinput-device.c
> > > @@ -190,9 +190,15 @@ normalize_scroll(struct libinput_event_pointer
> > > *pointer_event,
> > >*/
> > > switch (source) {
> > > case LIBINPUT_POINTER_AXIS_SOURCE_WHEEL:
> > > +#if HAVE_LIBINPUT_AXIS_V120
> > > + value = 10 * libinput_event_pointer_get_axis_value_v120(
> > > +
> > > pointer_event,
> > > +axis)/120.0;
> > >
> >
> > Hi Peter,
> >
> > spaces needed around the operator.
>
> thx, and I will submit a MR proper anyway, this was just a FYI patch to
> illustrate the world probably won't end if we add hi-res scrolling.
>
> > > +#else
> > > value = 10 * libinput_event_pointer_get_axis_value_discrete(
> > >
> > > pointer_event,
> > > axis);
> > > +#endif
> > > break;
> > > case LIBINPUT_POINTER_AXIS_SOURCE_FINGER:
> > > case LIBINPUT_POINTER_AXIS_SOURCE_CONTINUOUS:
> > > diff --git a/meson.build b/meson.build
> > > index 7826dbb0..dfb10ce5 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -143,6 +143,15 @@ dep_wayland_server = dependency('wayland-server',
> > > version: '>= 1.12.0')
> > > dep_wayland_client = dependency('wayland-client', version: '>= 1.12.0')
> > > dep_pixman = dependency('pixman-1', version: '>= 0.25.2')
> > > dep_libinput = dependency('libinput', version: '>= 0.8.0')
> > > +have_libinput_axis_v120_code = '''
> > > +#include
> > > +int main(void) { libinput_event_pointer_get_axis_value_v120(NULL, 0); }
> > > +'''
> > > +have_libinput_axis_v120 = cc.links(have_libinput_axis_v120_code,
> > > +name:
> > > 'libinput_event_pointer_get_axis_value_v120',
> > > +dependencies: dep_libinput)
> >
> > I guess the above gets replaced with a version check after libinput is
> > released?
>
> I found the direct function check works just as well and has the benefit of
> working with pre-releases (or patched versions) where needed. Esp. because
> here we just look for a single API call here. Do you have a preference?
Hi Peter,
maybe simply hard-require the new libinput release and don't even
bother with the #define below? But I suppose that could be inconvenient
for some.
Since it's just one function, I suppose I don't mind that much. The
version check would be much simpler in meson though.
Oh, you should probably use cc.has_function() instead of that
hand-written thing, that would help.
Thanks,
pq
> > > +config_h.set10('HAVE_LIBINPUT_AXIS_V120', have_libinput_axis_v120)
> > > +
pgpvE2cevx0Qe.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
