Re: Wayland / Weston Multi Display Client-Side Functionality

[Pekka Paalanen]

On Tue, 26 Feb 2019 00:11:45 +1300
Scott Anderson  wrote:

> On 25/02/19 8:21 pm, AMAR SEN wrote:
> > Hi,
> > 
> > 1. Is there any client side functionality to handle multiple displays? 
> > It can be seen as like a particular client has some options that can 
> > direct the server to show frames on either of the displays or both 
> > (multiple displays) of them at the same time. If it has such 
> > functionality, can somebody point me to an example implementation of 
> > such client?  
> 
> A normal Wayland client has no control regarding how it is placed by the 
> compositor, which is an intentional design decision.
> The most control I can think of (which may fit your use case), is that a 
> client can ask to be placed fullscreen on a particular output using the 
> fullscreen-shell protocol

Hi,

that is almost true, I just want to clarify a certain difference.

For desktop systems, the shell protocol extension used (wl_shell,
xdg_wm_base, ...) may offer a method of fullscreening to a specific
output. Aside from fullscreening, clients usually cannot affect where
they will positioned, by design. Proper positioning is the compositor's
responsibility.

Fullscreen shell extension is another beast completely, and mutually
exclusive to the desktop shell extensions. The fullscreen shell is
intended for a single client to take over all outputs, and does not
support multiple simultaneous clients. It also requires explicit
support from clients, and application toolkits usually do not have that.

> > 2. As I have read at multiple places that weston supports multi-display 
> > for drm based devices, is it also possible for fbdev backend, or it has 
> > some functionality constraint that do not let that to work on fbdev?  
> 
> I _think_ the fbdev backend does support multiple outputs. I've never 
> actually used the fbdev backend before, but the code implies that it 
> does. Either way, I would strongly recommend that you use the DRM 
> backend instead.

Right, please do not even consider using the fbdev backend for any new
projects. The only reason it has not been deleted yet is because there
may still be few lingering users. fbdev is in all ways inferior to the
DRM backend:
https://lists.freedesktop.org/archives/wayland-devel/2019-January/039877.html

Let fbdev die in peace, it has been almost dead for so many
years by now.

> 
> > 3. I am actually using weston-3.0.0 version for my project, does it have 
> > multi-display support for any backend? If yes, can someone please help 
> > me find  the commit to the wayland weston project which brought in the 
> > multi-display support?  
> 
> Just to be absolutely sure, are you just referring to having multiple 
> computer monitors ("heads") connected? I believe weston has always had 
> support for that.
> Later versions of weston are capable of cloning a monitor's contents 
> efficiently across multiple monitors, which may potentially be useful 
> for you.

Yes, Weston supports multiple outputs on the same graphics card.
Support for using multiple graphics cards is not there yet.


Thanks,
pq


pgpXkOWa_Atr3.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland / Weston Multi Display Client-Side Functionality

[Scott Anderson]

On 25/02/19 8:21 pm, AMAR SEN wrote:

Hi,

1. Is there any client side functionality to handle multiple displays? 
It can be seen as like a particular client has some options that can 
direct the server to show frames on either of the displays or both 
(multiple displays) of them at the same time. If it has such 
functionality, can somebody point me to an example implementation of 
such client?


A normal Wayland client has no control regarding how it is placed by the 
compositor, which is an intentional design decision.
The most control I can think of (which may fit your use case), is that a 
client can ask to be placed fullscreen on a particular output using the 
fullscreen-shell protocol


2. As I have read at multiple places that weston supports multi-display 
for drm based devices, is it also possible for fbdev backend, or it has 
some functionality constraint that do not let that to work on fbdev?


I _think_ the fbdev backend does support multiple outputs. I've never 
actually used the fbdev backend before, but the code implies that it 
does. Either way, I would strongly recommend that you use the DRM 
backend instead.


3. I am actually using weston-3.0.0 version for my project, does it have 
multi-display support for any backend? If yes, can someone please help 
me find  the commit to the wayland weston project which brought in the 
multi-display support?


Just to be absolutely sure, are you just referring to having multiple 
computer monitors ("heads") connected? I believe weston has always had 
support for that.
Later versions of weston are capable of cloning a monitor's contents 
efficiently across multiple monitors, which may potentially be useful 
for you.



Thanks,
Amar Sen


If you require more complex control of how Weston does window 
management, writing a Weston plugin would be the way to do that, as 
opposed to a client trying to take control (which it can't).


Scott

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Wayland / Weston Multi Display Client-Side Functionality

[AMAR SEN]

Hi,

1. Is there any client side functionality to handle multiple displays? It
can be seen as like a particular client has some options that can direct
the server to show frames on either of the displays or both (multiple
displays) of them at the same time. If it has such functionality, can
somebody point me to an example implementation of such client?

2. As I have read at multiple places that weston supports multi-display for
drm based devices, is it also possible for fbdev backend, or it has some
functionality constraint that do not let that to work on fbdev?

3. I am actually using weston-3.0.0 version for my project, does it have
multi-display support for any backend? If yes, can someone please help me
find  the commit to the wayland weston project which brought in the
multi-display support?

Thanks,
Amar Sen
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Chris Murphy]

On Fri, Feb 22, 2019 at 9:00 AM Pekka Paalanen  wrote:
>
> Hi Chris,
>
> that is some interesting background, but I feel like I didn't quite
> catch the point.
>
> If the CRTC color management pipeline (LUT-CTM-LUT + maybe more) is
> programmed according to the monitor's color profile, where would those
> "conflicting video card LUTs" arise from?

A common offender were games. They'd try to access the video card LUT
directly for effects, but then not reset it back to what it was,
rather reset it to a hardwired assumption the game makes, e.g. all
displays have gamma 2.2 so we'll just do that! A secondary offender
were display calibration programs, user would upgrade or get a
competing program and now you've got two startup applets that apply
conflicting LUTs and it may be deterministically wrong or it may be
subject to a race condition as to which applet applies.

The later problem has mostly vanished with the advent of an OS API for
reading the vcgt tag directly from the ICC profile set as the profile
for a particular display.

So who owns the pipeline? If it's shared, then anyone can use it and
not set it back the way they found it. Or alternatively if they're
going to mess with that pipeline, to have a kind of "reset" API for
the thing that ought to be mostly responsible for such a thing, e.g.
colord.



-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

On Mon, 18 Feb 2019 10:44:15 -0700
Chris Murphy  wrote:

> On Fri, Feb 1, 2019 at 3:43 AM Pekka Paalanen  wrote:
> >
> > On Thu, 31 Jan 2019 12:03:25 -0700
> > Chris Murphy  wrote:
> >  
> > > I'm pretty sure most every desktop environment and distribution have
> > > settled on colord as the general purpose service.
> > > https://github.com/hughsie/colord
> > > https://www.freedesktop.org/software/colord/  
> >
> > FWIW, Weston already has a small plugin to use colord. The only thing
> > it does to apply anything is to set the simplest form of the gamma
> > ramps.  
> 
> Short version:
> Having just briefly looked that code, my best guess is colord is
> probably reading a vcgt tag in the ICC profile for the display, and
> applying it to the video card LUT (or one of them anyway).
> 
> Super extra long version:
> In ancient times (two decades+) there was a clear separation between
> display calibration (change the device) and characterization (record
> its behavior). Calibration was a combination of resetting and fiddling
> with display controls like brightness and contrast, and then also
> leveraging the at best 8 bit per channel LUT in the video card to
> achieve the desired white point and tone curve per channel.
> Characterization, which results in an ICC profile, happens on top of
> that. The profile is valid only when the calibration is applied, both
> the knob fiddling part and the applicable LUT in the video card. The
> LUT information used to be kept in a separate file, and then circa 15
> years ago Apple started to embed this information into the ICC profile
> as the vcgt tag, and the operating system display manager reads that
> tag and applies it to the video card LUT prior to login time. This has
> become fairly widespread, even though I'm not finding vcgt in the
> published ICC v4.3 spec. But they do offer this document:
> www.color.org/groups/medical/displays/controllingVCGT.pdf
> 
> There are some test profiles that contain various vcgt tags here:
> http://www.brucelindbloom.com/index.html?Vcgt.html
> 
> You really must have a reliable central service everyone agrees on to
> apply such a LUT, and then also banning anything else from setting a
> conflicting LUT. Again in ancient times we had all sorts of problems
> with applications messing around with the LUT, and instead of reading
> it first and restoring it the same way, they just reset it to some
> default, thereby making the ICC profile invalid.
> 
> The primary reason, again historically, for setting the white point
> outside of software (ideally set correctly in the display itself; less
> ideal is using a video card LUT) is because mismatching white points
> are really distracting, it prevents proper adaptation, and therefore
> everything looks wrong. Ironically the color managed content is
> decently likely to look more wrong than non-color-managed content. Why
> would there be mismatching white points? Correct white point fully
> color managed content in an application window, but not any other
> application or the surrounding UI of the desktop environment.
> 
> Ergo, some kind of "calibration" of white point independent of the
> color management system. Sometimes this is just a preset in the
> display's on-screen menu. Getting the display white point in the ball
> park of target white point means a less aggressive LUT in the video
> card, or even ideally a linear LUT.
> 
> Alternatively, you decide you're going to have some master of all
> pixels. That's the concept of full display compensation, where every
> pixel is subject to color management transforms regardless of its
> source application, all normalized to a single intermediate color
> space. In theory if you throw enough bits at this intermediate space,
> you could forgo the video card LUT based calibration.
> 
> The next workflow gotcha, is multiple displays. In designing a color
> management system for an OS you have to decide if applications will
> have the option to display across multiple displays, each of which
> could have their own display profile.
> 
> I agree with Graeme that having different pipelines for calibration or
> characterization is asking for big trouble. The thing I worry about,
> is whether it's possible for each application to effectively have
> unique pipelines because they're all using different rendering
> libraries. The idea we'd have application specific characterization to
> account for each application pipeline just spells doom. The return of
> conflicting video card LUTs would be a nightmare.

Hi Chris,

that is some interesting background, but I feel like I didn't quite
catch the 

Re: [ANNOUNCE] weston 5.0.91

[Derek Foreman]

Hello,

Yes, something is wrong with CI for the web repository.  It's constantly
failing and refusing to deploy the new changes (updates to the release page
and the tarballs referenced in the release emails)

Hopefully resolved soon. :(

Thanks,
Derek

On Wed, 20 Feb 2019 at 06:03, Marius Vlad  wrote:

> Hi,
>
> FYI, The links at the end all give 404. Releases page is missing alpha
> version entry as well.
>
> On 2/19/19 10:15 PM, Derek Foreman wrote:
> > This is the alpha release for weston 6.0.  A lot has happened for this
> > release, some big items to note are:
> > We now have xdg-shell stable support!
> >
> > We've moved to meson as our primary build system and have deprecated the
> > autotools build entirely.  You need to run configure with
> > --enable-autotools to use autotools, and we will be removing autotools
> > after the 6.0 release.
> >
> > Full commit history follows:
> >
> > Alexandros Frantzis (11):
> >   xwayland: Silence format-truncation compilation warnings
> >   clients: Add simple-dmabuf-egl
> >   clients/simple-dmabuf-egl: Support dmabuf format modifiers
> >   clients/simple-dmabuf-egl: Render a moving square
> >   libweston: Introduce zwp_linux_explicit_synchronization_v1
> >   libweston: Introduce an internal linux sync file API
> >   libweston: Support zwp_surface_synchronization_v1.set_acquire_fence
> >   libweston: Support zwp_surface_synchronization_v1.get_release
> >   tests: Add tests for per commit zwp_buffer_release_v1 behavior
> >   clients: Support explicit synchronization in simple-dmabuf-egl
> >   clients: Add a mandelbrot set shader to simple-dmabuf-egl
> >
> > Arkadiusz Hiler (1):
> >   compositor-drm: Log atomic commits and flips
> >
> > Changwoo Cho (1):
> >   libweston: fix typo in comment
> >
> > Daniel Stone (14):
> >   CONTRIBUTING: How do I get started?
> >   compositor: Add weston_layer_mask_is_infinite
> >   compositor: Add scene-graph debug scope
> >   compositor-drm: Calculate atomic-commit flags earlier
> >   compositor-drm: Add backend pointer to drm_output
> >   compositor-drm: Add drm-backend log debug scope
> >   gl-renderer: Remove warning on missing extensions
> >   compositor-drm: Don't warn about missing backlight control
> >   tests: Rename surface-screenshot
> >   tests: fix include in input-timestamps-helper.c
> >   Add Meson build system
> >   CI: Add Meson build
> >   gitlab-ci: Actually capture Meson logs
> >   compositor-drm: Fall back if GBM surface fails with modifiers
> >
> > David Fort (1):
> >   rdp-compositor: fix compilation with FreeRDP 2.0-rc4
> >
> > Deepak Rawat (1):
> >   compositor-drm: Read FB2_MODIFIERS capability
> >
> > Derek Foreman (2):
> >   configure.ac: Reopen master for regular development
> >   configure.ac: bump to version 5.0.91 for the alpha release
> >
> > Dima Ryazanov (4):
> >   Don't look for weston.ini in the current working directory
> >   Revert "Fix a crash when unlocking or unconfining a pointer"
> >   clients: Delete an unused variable
> >   clients: A better fix for a crash when unlocking or unconfining a
> > pointer
> >
> > Emil Velikov (2):
> >   libweston: split EGL and GL info logging
> >   libweston: print EGL information as early as possible
> >
> > Emmanuel Gil Peyrot (1):
> >   ivi-shell: Add missing sentence point
> >
> > Emre Ucan (7):
> >   ivi-shell: Add build_view_list function
> >   ivi-shell: unmap views which are not in scenegraph
> >   ivi-shell: check ivi_view mappedness in commit_changes()
> >   ivi-shell: don't use input panel implementation
> >   ivi-shell: remove input panel implementation
> >   ivi-shell: remove unused functions and members
> >   ivi-shell: remove input-method section from config
> >
> > Eric Engestrom (2):
> >   meson: fix -Wno-foo argument testing
> >   Revert "meson: fix -Wno-foo argument testing"
> >
> > Eric Toombs (3):
> >   man: fix small typo: directroy
> >   weston: deprecate enable_tap in favour of enable-tap
> >   weston: add more libinput config options
> >
> > Greg V (8):
> >   build: use pkg-config to find libjpeg in meson
> >   build: use '-Wl,' wrapper for the -export-dynamic linker flag
> >   build: add missing wayland-cli

[ANNOUNCE] weston 5.0.91

[Derek Foreman]

This is the alpha release for weston 6.0.  A lot has happened for this
release, some big items to note are:
We now have xdg-shell stable support!

We've moved to meson as our primary build system and have deprecated the
autotools build entirely.  You need to run configure with
--enable-autotools to use autotools, and we will be removing autotools
after the 6.0 release.

Full commit history follows:

Alexandros Frantzis (11):
  xwayland: Silence format-truncation compilation warnings
  clients: Add simple-dmabuf-egl
  clients/simple-dmabuf-egl: Support dmabuf format modifiers
  clients/simple-dmabuf-egl: Render a moving square
  libweston: Introduce zwp_linux_explicit_synchronization_v1
  libweston: Introduce an internal linux sync file API
  libweston: Support zwp_surface_synchronization_v1.set_acquire_fence
  libweston: Support zwp_surface_synchronization_v1.get_release
  tests: Add tests for per commit zwp_buffer_release_v1 behavior
  clients: Support explicit synchronization in simple-dmabuf-egl
  clients: Add a mandelbrot set shader to simple-dmabuf-egl

Arkadiusz Hiler (1):
  compositor-drm: Log atomic commits and flips

Changwoo Cho (1):
  libweston: fix typo in comment

Daniel Stone (14):
  CONTRIBUTING: How do I get started?
  compositor: Add weston_layer_mask_is_infinite
  compositor: Add scene-graph debug scope
  compositor-drm: Calculate atomic-commit flags earlier
  compositor-drm: Add backend pointer to drm_output
  compositor-drm: Add drm-backend log debug scope
  gl-renderer: Remove warning on missing extensions
  compositor-drm: Don't warn about missing backlight control
  tests: Rename surface-screenshot
  tests: fix include in input-timestamps-helper.c
  Add Meson build system
  CI: Add Meson build
  gitlab-ci: Actually capture Meson logs
  compositor-drm: Fall back if GBM surface fails with modifiers

David Fort (1):
  rdp-compositor: fix compilation with FreeRDP 2.0-rc4

Deepak Rawat (1):
  compositor-drm: Read FB2_MODIFIERS capability

Derek Foreman (2):
  configure.ac: Reopen master for regular development
  configure.ac: bump to version 5.0.91 for the alpha release

Dima Ryazanov (4):
  Don't look for weston.ini in the current working directory
  Revert "Fix a crash when unlocking or unconfining a pointer"
  clients: Delete an unused variable
  clients: A better fix for a crash when unlocking or unconfining a
pointer

Emil Velikov (2):
  libweston: split EGL and GL info logging
  libweston: print EGL information as early as possible

Emmanuel Gil Peyrot (1):
  ivi-shell: Add missing sentence point

Emre Ucan (7):
  ivi-shell: Add build_view_list function
  ivi-shell: unmap views which are not in scenegraph
  ivi-shell: check ivi_view mappedness in commit_changes()
  ivi-shell: don't use input panel implementation
  ivi-shell: remove input panel implementation
  ivi-shell: remove unused functions and members
  ivi-shell: remove input-method section from config

Eric Engestrom (2):
  meson: fix -Wno-foo argument testing
  Revert "meson: fix -Wno-foo argument testing"

Eric Toombs (3):
      man: fix small typo: directroy
  weston: deprecate enable_tap in favour of enable-tap
  weston: add more libinput config options

Greg V (8):
  build: use pkg-config to find libjpeg in meson
  build: use '-Wl,' wrapper for the -export-dynamic linker flag
  build: add missing wayland-client dep in meson
  desktop-shell: extract view_get_transform, make it reliable
  xwayland: fix clipboard related crash
  xwm: fix resize grab related crash
  desktop-shell: fix resize grab related crash
  desktop-shell: remove surface destroy listener when focus state is
destroyed

Jonas Ã…dahl (1):
  gitlab-ci.yml: Install meson from 0.49 branch

Marius Vlad (25):
  pixel-formats: Added pixel_format_get_info_shm() helper for printing
SHM buffers
  compositor: Make pixel format printing in human-friendly form
  Fix compiler warnings generated by older toolchains/compiler
  Fix compiler warnings: clobber variables
  Fix compiler warnings: invalid type format
  Fix compiler warning: unused variable when building with DEBUG
  libweston/compositor-drm: Print composition mode in weston-debug
  libweston/compositor-drm: No need to test for invalid alpha for the
view
  libweston/compositor-drm: Add missing debug message for scanout_view
  clients/screenshot: Avoid using global variables to pass down data
between functions
  clients/screenshot: Allow weston-screenshooter to be called directly
  libweston/weston-debug: Add a easy way to determine if the debug
protocol has been enabled
  libweston: Allow taking screenshots when debug protocol is enabled
  ivi-shell/hmi-controller: Include

Weston/wayland release schedule

[Derek Foreman]

Hello,

Thanks everyone for the flurry of activity reviewing and landing important
patches for the release!

In agreement with Daniel's suggestion to freeze and release today, I'm
going to start rolling the alpha shortly.  Here's the final release
schedule:

Alpha: today, February 19th
Beta: March 5th
Rc1: March 12th
March 19th - first potential final release date.

Thanks,
Derek
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Chris Murphy]

On Fri, Feb 1, 2019 at 3:43 AM Pekka Paalanen  wrote:
>
> On Thu, 31 Jan 2019 12:03:25 -0700
> Chris Murphy  wrote:
>
> > I'm pretty sure most every desktop environment and distribution have
> > settled on colord as the general purpose service.
> > https://github.com/hughsie/colord
> > https://www.freedesktop.org/software/colord/
>
> FWIW, Weston already has a small plugin to use colord. The only thing
> it does to apply anything is to set the simplest form of the gamma
> ramps.

Short version:
Having just briefly looked that code, my best guess is colord is
probably reading a vcgt tag in the ICC profile for the display, and
applying it to the video card LUT (or one of them anyway).

Super extra long version:
In ancient times (two decades+) there was a clear separation between
display calibration (change the device) and characterization (record
its behavior). Calibration was a combination of resetting and fiddling
with display controls like brightness and contrast, and then also
leveraging the at best 8 bit per channel LUT in the video card to
achieve the desired white point and tone curve per channel.
Characterization, which results in an ICC profile, happens on top of
that. The profile is valid only when the calibration is applied, both
the knob fiddling part and the applicable LUT in the video card. The
LUT information used to be kept in a separate file, and then circa 15
years ago Apple started to embed this information into the ICC profile
as the vcgt tag, and the operating system display manager reads that
tag and applies it to the video card LUT prior to login time. This has
become fairly widespread, even though I'm not finding vcgt in the
published ICC v4.3 spec. But they do offer this document:
www.color.org/groups/medical/displays/controllingVCGT.pdf

There are some test profiles that contain various vcgt tags here:
http://www.brucelindbloom.com/index.html?Vcgt.html

You really must have a reliable central service everyone agrees on to
apply such a LUT, and then also banning anything else from setting a
conflicting LUT. Again in ancient times we had all sorts of problems
with applications messing around with the LUT, and instead of reading
it first and restoring it the same way, they just reset it to some
default, thereby making the ICC profile invalid.

The primary reason, again historically, for setting the white point
outside of software (ideally set correctly in the display itself; less
ideal is using a video card LUT) is because mismatching white points
are really distracting, it prevents proper adaptation, and therefore
everything looks wrong. Ironically the color managed content is
decently likely to look more wrong than non-color-managed content. Why
would there be mismatching white points? Correct white point fully
color managed content in an application window, but not any other
application or the surrounding UI of the desktop environment.

Ergo, some kind of "calibration" of white point independent of the
color management system. Sometimes this is just a preset in the
display's on-screen menu. Getting the display white point in the ball
park of target white point means a less aggressive LUT in the video
card, or even ideally a linear LUT.

Alternatively, you decide you're going to have some master of all
pixels. That's the concept of full display compensation, where every
pixel is subject to color management transforms regardless of its
source application, all normalized to a single intermediate color
space. In theory if you throw enough bits at this intermediate space,
you could forgo the video card LUT based calibration.

The next workflow gotcha, is multiple displays. In designing a color
management system for an OS you have to decide if applications will
have the option to display across multiple displays, each of which
could have their own display profile.

I agree with Graeme that having different pipelines for calibration or
characterization is asking for big trouble. The thing I worry about,
is whether it's possible for each application to effectively have
unique pipelines because they're all using different rendering
libraries. The idea we'd have application specific characterization to
account for each application pipeline just spells doom. The return of
conflicting video card LUTs would be a nightmare.

--
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Kai-Uwe]

Hello Chris,

Am 31.01.19 um 20:03 schrieb Chris Murphy:
> On Wed, Jan 30, 2019 at 10:54 PM Nautiyal, Ankit K
>  wrote:
>>  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?
> I'm pretty sure most every desktop environment and distribution have
> settled on colord as the general purpose service.


Chris is quite involved in _colord_ consultancy as a color management
__consultant__ and writes books about color management. But he do not
tell anywhere about these commercial interest clash. Are face down cards
common advertising practice in the US?

regards

Kai-Uwe Behrmann
-- 
www.oyranos.org - Color Management System project lead
www.behrmann.name - coding for various open source and commercial color
projects


PS: To make it clear, I am fine that different people speak up their
technical opinion, including about their own business products. As long
as it is publicly visible in a email and has technical benefit.

PPS: sorry for the late noice, and of course great to see the topic
becoming lively again


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Graeme Gill]

Chris Murphy wrote:

Hi Chris,

> I'm pretty sure most every desktop environment and distribution have
> settled on colord as the general purpose service.
> https://github.com/hughsie/colord
> https://www.freedesktop.org/software/colord/

right, but colord is not needed to run X11 color management.
Using ArygyllCMS to load profiles on startup is a viable alternative.
There is also Oyranos.

The experience of trying to get better integration between
colord and color management tools like ArgyllCMS is one of
the things that informs my views on a Wayland color management
protocol. (i.e. it doesn't currently work, even though it
used to at one point.) Having a neutral and consistently
implemented API for color managed clients and color management
tools would be a very good thing.

> By default, colord will create a display profile on-the-fly, for
> attached displays, based on display provided EDID information.

Certainly a useful approach a system may take to providing default
display profiles.

> You'd want to evaluate the interfaces of Argyll CMS and lcms2; it's
> possible you'd use Argyll CMS for profile creation, and lcms2 as the
> transformation engine, for example.

ArgyllCMS's CMM probably isn't a choice for some compositor implementations,
due to its GPL licensing, and current lack of support for ICCV4. I don't think
that it has any noticeable speed advantage of lcms2 for 3 channel conversions
either, and lcms is much better integrated as a drop in CMM. Its plug in
architecture may be an advantage in implementing the HDR tweaks needed,
as well as those wishing to optimize compositor color management performance.

Cheers,
Graeme.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Graeme Gill]

 the aim of
a system that is intended to suite the users purposes. An update
that contained changes that altered the color response of a system
would be disruptive, and would have to come with a bunch of
warnings, i.e. "You need to re-profile your display after applying
this update". Just like any other system update, this is not a situation
that would be created lightly by a responsible software development team.

> Wayland has a different paradigm that I have been trying to explain.
> 
> You said the measuring application needs to be able to show content
> unhindered by the compositor. I agree, and for that we need a Wayland
> extension taking into account the special details of measuring, e.g.
> how to position the color patch you want to physically measure and many
> many more aspects that an application cannot control using public
> unprivileged interfaces alone.

There isn't that much too it. Being able to install a profiles & calibration
curves (something the compositor needs at startup anyway). Being able to display
output at a particular location on a particular output (something that the
input calibration has had to tackle too.) Being able to label the color test 
values
in such a way that they don't have color management applied (something
that is part of the client color management protocol). That's about it.
Yes, some of these will require consideration of privilege levels.

> "Install a profile" into the compositor has these drawbacks the very
> least:
> 
> - "installing" is a global action, hence it means the application is
>   hijacking at least a whole output if not the whole compositor to
>   itself, this must be separate from the general application usage as it
>   needs to be privileged and exclusive

I'm not sure what you mean by "hijacking". Typically on systems installation
of display profiles is per-user, with system defaults being a privileged 
operation.
It certainly doesn't have much impact on other applications. A color
aware application might like to be notified that a color profile it has
downloaded from the compositor has changed, but non color managed
application can be blissfully ignorant. A compositor will probably want
to re-convert buffers that used the profile that was updated.

> - it assumes that the compositor works in a very specific way, that may
>   not match the hardware it has to work with, maybe avoiding the full
>   potential of the hardware

You'll have to give me an example, because I don't know what
you are thinking of.

> - the profile is for an output as a whole, which means that if you
>   installed a profile that includes effects from pixel formats and
>   source color spaces, you cannot show other applications on the same
>   output correctly

That's the nature of system provided color management. A client
that implicitly or explicitly uses the system facility gets
the plain vanilla fallback. Any application that wants to have
more control can do so, by doing its own conversions to the
specific display space. Profile installation is a users
choice, they are in control of what profiles they make, and
what ones they install. Defaults profiles should be designed to be useful.

> Yes, it works through and in cooperation with the compositor. It needs
> the compositor cooperation to be able to turn off the input coordinate
> transformation that the compositor normally does, and it needs to
> hijack that one input device completely. There is no other interface
> that would allow it to do that than the (Weston-specific) Wayland
> extension specifically designed for it.

An alternative approach would have been to have the calibration application
install a unity mapping that was applied just to it. It would
then get the raw coordinates, and could then install the calibrated
mapping. i.e. I'm not convinced that a special mode is actually needed
in the protocol design, apart from the facility to display graphics
at specific points on the display.

> Another advantage of the explicit special interface is that if the
> measurement application happens to crash, the compositor will restore
> normality automatically. The same happens if the user decides to
> forcefully quit the measurement, e.g. the measurement application is
> misbehaving: the compositor can offer an easy exit.

Right, but I would assume this is the case with any normal client.
A color profiling application doesn't set the display to any significantly
different condition to it's normal operation. I would assume that
temporarily installed profiles/calibration would be automatically un-installed
on the client quitting, along with any surfaces it is using etc.

> (Ever had a game
> change the video mode on X11 and then all your desktop icons are piled
> into the top-left corner, or the game crashes an

[PATCH wayland-web] xserver: how to let Weston find Xwayland

[Pekka Paalanen]

From: Pekka Paalanen 

Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/188

Signed-off-by: Pekka Paalanen 
---
 xserver.html | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/xserver.html b/xserver.html
index 174b2ab..000f743 100644
--- a/xserver.html
+++ b/xserver.html
@@ -106,6 +106,17 @@ Add this to ~/.config/weston.ini (or use the 
--xwayland co
 xwayland=true
 
 
+
+If the default search path for Xwayland in Weston is not correct,
+you need to fix it either by a Weston build option xwayland-path
+or adding this to ~/.config/weston.ini:
+
+
+
+[xwayland]
+path=/path/to/bin/Xwayland
+
+
 Running
 
 
-- 
2.20.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

On Thu, 31 Jan 2019 12:03:25 -0700
Chris Murphy  wrote:

> Hi Ankit,
> 
> 
> On Wed, Jan 30, 2019 at 10:54 PM Nautiyal, Ankit K
>  wrote:
> >
> > 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?  
> 
> I'm pretty sure most every desktop environment and distribution have
> settled on colord as the general purpose service.
> https://github.com/hughsie/colord
> https://www.freedesktop.org/software/colord/

FWIW, Weston already has a small plugin to use colord. The only thing
it does to apply anything is to set the simplest form of the gamma
ramps.


Thanks,
pq


pgpw9OyKyJhJd.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Weston error

[Andrzej Czerwiński]

weston[30514]: segfault at 55813301b3c0 ip 55813301b3c0 sp 
7ffe1994ac58 error 15
[ 2752.917756] Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 61 04 00 00 00 00 00 
00  b9 46 33 81 55 00 00 c8 0b 02 33 81 55 00 00 00 39 01 33 81 55


gtk3


The error is during a new pop-up window in the gtkentry widget (pop-up 
menu).



When the parent window is closed, this error occurs.

--
Z poważaniem
Andrzej Czerwiński

M: +48 511 851 776
E: a...@ebit.ac

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Weston GL shader compilation re-design

[Daniel Stone]

Hi Harish,

On Wed, 23 Jan 2019 at 09:35, Pekka Paalanen  wrote:
> On Wed, 23 Jan 2019 11:32:34 +0530 Harish Krupo  
> wrote:
> > 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.
>
> 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 can see compositor-specific effect shaders (e.g. desaturation or
blurring of inactive windows) maybe needing access to function-local
variables. What I had in mind for this was something similar to Cogl's
shader snippets:
https://developer.gnome.org/cogl-2.0-experimental/stable/cogl-2.0-experimental-Shader-snippets.html

I'd be happy with either approach to begin with though; maybe a more
limited approach is best right now.

You're right that unused functions (even unused statements or branches
mostly, these days) will get eliminated by the compiler and not make
it to final GPU bytecode.

> 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?

I don't think we really need a megashader. Switching between different
shaders is quite cheap (we already switch a great deal of state when
moving between views anyway), and there's no compilation overhead. I'd
much rather do that for now.

> 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.

If we discover that some parts of the pipeline need ESSL3.x to
function properly, we could just not advertise those bits unless we
have ES3.x. In any case, if we start requiring newer ESSL versions or
extensions, we'll likely need #pragmas at the top of the shader to
enable them, which means we have to do a little bit more than purely
concatenating functions anyway.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Chris Murphy]

Hi Ankit,


On Wed, Jan 30, 2019 at 10:54 PM Nautiyal, Ankit K
 wrote:
>
> 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?

I'm pretty sure most every desktop environment and distribution have
settled on colord as the general purpose service.
https://github.com/hughsie/colord
https://www.freedesktop.org/software/colord/

By default, colord will create a display profile on-the-fly, for
attached displays, based on display provided EDID information. There
can be buggy EDID, and in practice there are no display updates to fix
it after the product ships. Whether this is sanity checked prior to
building a profile, or later, depends on the policy of the platform at
the time the buggy EDID is encountered. Where it's sanity checked also
varies: it could be the platform specific profile manager e.g. colord;
the color management module (CMM) which is the engine that uses
profiles to perform color space transforms; or it could happen at the
application level.

Profiles are sometimes packaged with applications, sometimes stand
alone. Argyll CMS includes a bunch of standardized RGB profiles,
Ghostscript includes another set, and colord includes some as well.

You're definitely best off deferring to tools that specialize in
creating ICC profiles rather than building them yourself.


> 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?

You'd want to evaluate the interfaces of Argyll CMS and lcms2; it's
possible you'd use Argyll CMS for profile creation, and lcms2 as the
transformation engine, for example.

http://www.littlecms.com/

-- 
Chris Murphy
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Nautiyal, Ankit K]

Thanks for the clarification Ole.

Regards,

Ankit


On 1/31/2019 2:22 PM, Niels Ole Salscheider wrote:

Hi Ankit,

please find my answers below.

Am Donnerstag, 31. Januar 2019, 06:54:03 CET schrieb Nautiyal, Ankit K:

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.

The compositor will know about a few widely used ICC profiles. In my proposal
this is sRGB but we could also add e. g. a HDR profile. If the client wants to
use one of these profiles it can just tell the compositor and use it. If the
client wants to provide the surface in any other color space it has to create
a matching color profile from an ICC profile. For that the client passes a
file descriptor to the profile to the compositor. The file descriptor might
correspond to a file on the hard disk (where it was installed by the client/
toolkit/some third party) or to some temporary file created by the client. In
the latter case the data might for example come from the embedded profile of
an image or it might have been composed by the client.


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?

Yes, there are open source libraries to handle .icc files. You already
mentioned ArgyllCMS. There is also LittleCMS which is easy to use and enough
for a lot of usecases.

Best regards,

Ole


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.h
tml

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.ht
ml

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 

Re: HDR support in Wayland/Weston

[Niels Ole Salscheider]

Hi Ankit,

please find my answers below.

Am Donnerstag, 31. Januar 2019, 06:54:03 CET schrieb Nautiyal, Ankit K:
> 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.

The compositor will know about a few widely used ICC profiles. In my proposal 
this is sRGB but we could also add e. g. a HDR profile. If the client wants to 
use one of these profiles it can just tell the compositor and use it. If the 
client wants to provide the surface in any other color space it has to create 
a matching color profile from an ICC profile. For that the client passes a 
file descriptor to the profile to the compositor. The file descriptor might 
correspond to a file on the hard disk (where it was installed by the client/
toolkit/some third party) or to some temporary file created by the client. In 
the latter case the data might for example come from the embedded profile of 
an image or it might have been composed by the client.

> 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?

Yes, there are open source libraries to handle .icc files. You already 
mentioned ArgyllCMS. There is also LittleCMS which is easy to use and enough 
for a lot of usecases.

Best regards,

Ole

> 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.h
> > tml
> > 
> > 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.ht
> > ml
> > 
> > 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)
&g

Re: HDR support in Wayland/Weston

[Nautiyal, Ankit K]

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.
  -

Re: [PATCH RFC weston] libinput: support high-resolution scroll wheels

[Pekka Paalanen]

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

Re: [PATCH RFC weston] libinput: support high-resolution scroll wheels

[Peter Hutterer]

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?

> > +config_h.set10('HAVE_LIBINPUT_AXIS_V120', have_libinput_axis_v120)
> > +
> >  dep_libm = cc.find_library('m')
> >  dep_libdl = cc.find_library('dl')
> >  dep_libdrm = dependency('libdrm', version: '>= 2.4.68')
> 
> Fine by me, but I can't claim to have actually verified the correctness
> of the semantics. A Weston MR would be cool, if you prefix the title
> with "WIP:" Gitlab makes it unmergeable until the prefix is removed. :-)

Testing a bit more yesterday, there's some issue with Firefox (double
scrolling) that I haven't identified yet, but expect the MR to show up once
I know what it is.

Cheers,
   Peter
___
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

[Peter Hutterer]

On Tue, Jan 29, 2019 at 02:19:08PM +, Simon Ser wrote:
> On Tuesday, January 29, 2019 7:57 AM, Peter Hutterer 
>  wrote:
> > 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;
> > +#else
> > value = 10 * libinput_event_pointer_get_axis_value_discrete(
> >
> > pointer_event,
> >axis);
> > +#endif
> 
> Just a general libinput question: in wlroots, we just use
> libinput_event_pointer_get_axis_value regardless of the source. Is the
> multiply-by-10 workaround supposed to be implemented in all
> compositors?

it's a backwards-compatibility thing Weston has (and mutter too). The
wayland protocol says that pointer axis x/y are the same dimension as
pointer movement. Early during Weston's development and before libinput was
split out a mouse wheel was set to 10. libinput later changed the API in
favour of physical angles (that's what we use virtually everywhere in the
API) but the 10 stayed in place.

if you don't have the factor 10 here and you just pass libinput values on,
it means your mouse is going to scoll a hardware-dependent amount of motion 
for every wheel movement. That's 15 for 90+% of all mice, 20 for some [1],
others are quite rare.

Whether 10 is the right value or 12, 15, whatever are better I can't really
comment on, I simply never looked into it.

Cheers,
   Peter

[1] those 20 degree click mice are sold as "fine-grained scrolling", so
there's an argument to be made to normalize into a smaller range to deliver
on what the cardboard box says.
___
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

[Simon Ser]

On Tuesday, January 29, 2019 7:57 AM, Peter Hutterer  
wrote:
>   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;
> +#else
>   value = 10 * libinput_event_pointer_get_axis_value_discrete(
>  
> pointer_event,
>  axis);
> +#endif

Just a general libinput question: in wlroots, we just use
libinput_event_pointer_get_axis_value regardless of the source. Is the
multiply-by-10 workaround supposed to be implemented in all
compositors?
___
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

[Pekka Paalanen]

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.

> +#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?

> +config_h.set10('HAVE_LIBINPUT_AXIS_V120', have_libinput_axis_v120)
> +
>  dep_libm = cc.find_library('m')
>  dep_libdl = cc.find_library('dl')
>  dep_libdrm = dependency('libdrm', version: '>= 2.4.68')

Fine by me, but I can't claim to have actually verified the correctness
of the semantics. A Weston MR would be cool, if you prefix the title
with "WIP:" Gitlab makes it unmergeable until the prefix is removed. :-)


Thanks,
pq


pgp6A9vLK2dGR.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

ibration it just has to send device RGB values
> through the installed calibration curves. To verify profile
> conversion it just has to label its test RGB values with a known
> source space profile. More complex from a Wayland point of view
> appears to be getting control of the test window output, location
> & size (although I get the impression some of this is doable using
> xdg protocols ?)

I agree on the goals, but I disagree on how to achieve them.

XDG extensions won't help you there.

"Install a profile" into the compositor has these drawbacks the very
least:

- "installing" is a global action, hence it means the application is
  hijacking at least a whole output if not the whole compositor to
  itself, this must be separate from the general application usage as it
  needs to be privileged and exclusive

- it assumes that the compositor works in a very specific way, that may
  not match the hardware it has to work with, maybe avoiding the full
  potential of the hardware

- the profile is for an output as a whole, which means that if you
  installed a profile that includes effects from pixel formats and
  source color spaces, you cannot show other applications on the same
  output correctly

> > As an example of orthogonality, I would like to point to the new
> > touchscreen calibration tool for Weston. Commit adding the new tool
> > lists the benefits it has over the old calibration tool that was using
> > the usual input interfaces in Wayland:
> > https://gitlab.freedesktop.org/wayland/weston/commit/b79dead1dded6744d251da5357e14c83b91cef32
> >   
> 
> Right, but that seems to be an application that works through the compositor,
> not around it ? Having a special mode to turn off color calibration curves
> isn't necessary - installing linear per channel curves is all that's needed
> and avoids extra (confusing) API's.

Yes, it works through and in cooperation with the compositor. It needs
the compositor cooperation to be able to turn off the input coordinate
transformation that the compositor normally does, and it needs to
hijack that one input device completely. There is no other interface
that would allow it to do that than the (Weston-specific) Wayland
extension specifically designed for it.

Another advantage of the explicit special interface is that if the
measurement application happens to crash, the compositor will restore
normality automatically. The same happens if the user decides to
forcefully quit the measurement, e.g. the measurement application is
misbehaving: the compositor can offer an easy exit. (Ever had a game
change the video mode on X11 and then all your desktop icons are piled
into the top-left corner, or the game crashes and leaves your monitor
in low-resolution mode where you can't even see a desktop settings
dialog in full? Automatic recovery and explicit action intents helped
also those use cases.)

Likewise, color measuring needs to make "the curves" linear like you
say, and it needs to hijack one output completely. There is no
interface that would allow the measurement application to do that, so
one needs to be designed according to the Wayland paradigm.

> > The reason the extension is specific to Weston is that there was no
> > interest in making it a standard, no-one else saw the need to calibrate
> > touchscreen input. It could still be standardised if the interest
> > arises.  
> 
> Sure, and having a defined protocol and example implementation in Weston
> is about all one can expect in the case of color management. Having
> a working example and tools and applications that have been proven to
> work correctly with the implementation provides a path for wider adoption
> when demand arises.

I think a color management related extension for content delivery should
aim higher than that from the start: to wayland-protocols as an unstable
extension. The cross-compositor and toolkit demand exists already.

An analogy to the touchscreen calibration case is wl_touch which is
the public unprivileged interface that touchscreen apps are already
using. wl_touch only happens to be in Wayland core because it was
designed early in Wayland's life. The original touchscreen calibration
app used wl_touch, and was found to be sorely lacking because of it.

> > Likewise, measuring the color characteristics of a monitor will likely
> > require a notion of intent to a Wayland compositor. Not only one wants
> > to be absolutely sure the compositor is not mangling the pixel data,  
> 
> Quite the contrary - see above. If the compositor is mangling all the
> pixel data, then it needs to mangled in exactly the same way while
> profiling so that the response is the same and so that the profile
> is valid for the compositor mangling pixel data that way. To have
> it un-mangled while profiling, yet mangled for all the applications
> means that the profile is invalid.

I believe we can do better than that.


Thanks,
pq


pgpTN5ypQvDFy.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH RFC weston] libinput: support high-resolution scroll wheels

[Peter Hutterer]

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;
+#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)
+config_h.set10('HAVE_LIBINPUT_AXIS_V120', have_libinput_axis_v120)
+
 dep_libm = cc.find_library('m')
 dep_libdl = cc.find_library('dl')
 dep_libdrm = dependency('libdrm', version: '>= 2.4.68')
-- 
2.20.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Graeme Gill]

the TV manufacturer
didn't bother supporting the various YCbCr encodings and hard
coded it to decode Rec601 YCbCr. So there is a hidden color
change going on when Wayland is running as well as some
minor quantization errors being introduced. But if the color
profiling application was to configure the hardware, it
may instead setup the HDMI in RGB mode (being the one
with the highest fidelity), and the color response won't
be the same as Wayland, so the profile made this way will
be invalid. Ensuring the graphics card and every other
element in the rendering pipeline is setup the same way,
by the same software, this hard to diagnose type of error is avoided.

Another aspects is that this raises considerably higher
barriers for translating the the profiling application onto wayland,
since it then has to bring it's own GUI/application layer to be able
to driver the display and get user input.

[ And consider that a full on color management application does
  a whole lot more that calibrate & profile displays, such as
  profiling printers, scanners, cameras, examining and previewing
  profiles images etc. etc. ]

> DRM Leases could make such a tool usable under a
> Wayland compositor, too, so you can have a control UI window as a
> Wayland window on another output. 

Doesn't that assume there is more than one output ?

Note that profiling tools typically provide a lot of
on screen guidance when making measurements, including where
to position the instrument, progress of patches etc.

See <https://www.youtube.com/watch?v=LFp-jBwMFFc>,
<https://www.youtube.com/watch?v=lXtSaLi9ZZE> etc. for a typical examples.

> People can take advantage of color
> managed output already while the community figures out a good way to
> handle measuring.

I'm quite not sure what you mean by that, since the actual measuring (i.e.
obtaining instrument values) is a solved problem. What has to be done
for Wayland is installing calibration curves and profiles. As long as
the profiling application can do that, then it can proceed with
calibration, profiling, installing and verification.

It's unnecessarily complicated (and more fraught with mistakes, see
above) to have some sort of special calibration mode. To send device
RGB to the display, all the profiling application has to do
is mark the source colorspace as being the same profile as the
corresponding output profile. To turn calibration curves off,
all it has to do is temporarily install a profile with linear per
channel curves. At the end of the process all it has to do is install
the computed profile & calibration curves permanently.
To verify calibration it just has to send device RGB values
through the installed calibration curves. To verify profile
conversion it just has to label its test RGB values with a known
source space profile. More complex from a Wayland point of view
appears to be getting control of the test window output, location
& size (although I get the impression some of this is doable using
xdg protocols ?)

> As an example of orthogonality, I would like to point to the new
> touchscreen calibration tool for Weston. Commit adding the new tool
> lists the benefits it has over the old calibration tool that was using
> the usual input interfaces in Wayland:
> https://gitlab.freedesktop.org/wayland/weston/commit/b79dead1dded6744d251da5357e14c83b91cef32

Right, but that seems to be an application that works through the compositor,
not around it ? Having a special mode to turn off color calibration curves
isn't necessary - installing linear per channel curves is all that's needed
and avoids extra (confusing) API's.

> The reason the extension is specific to Weston is that there was no
> interest in making it a standard, no-one else saw the need to calibrate
> touchscreen input. It could still be standardised if the interest
> arises.

Sure, and having a defined protocol and example implementation in Weston
is about all one can expect in the case of color management. Having
a working example and tools and applications that have been proven to
work correctly with the implementation provides a path for wider adoption
when demand arises.

> Likewise, measuring the color characteristics of a monitor will likely
> require a notion of intent to a Wayland compositor. Not only one wants
> to be absolutely sure the compositor is not mangling the pixel data,

Quite the contrary - see above. If the compositor is mangling all the
pixel data, then it needs to mangled in exactly the same way while
profiling so that the response is the same and so that the profile
is valid for the compositor mangling pixel data that way. To have
it un-mangled while profiling, yet mangled for all the applications
means that the profile is invalid.

Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Should Weston wait for client buffers to finish rendering?

[Pekka Paalanen]

On Thu, 24 Jan 2019 11:47:30 +0200
Pekka Paalanen  wrote:

> On Wed, 23 Jan 2019 18:43:52 +
> "Singh, Satyeshwar"  wrote:
> 
> > Imagine a benchmark case where the client renders for example 800
> > frames and attaches their buffer ids to a surface, the compositor
> > uses the last one that came in before its repaint cycle started for
> > composition and display on the screen. This buffer may not have been
> > rendered by the GPU yet because it is working on previous buffers.
> > However, it may not finish before the next Vblank and if it doesn't
> > finish, then the compositor's scan out buffer also isn't going to be
> > displayed by the kernel driver. If we change the policy for the
> > compositor to always use the last finished buffer, then at least the
> > compositor's scan out buffer will be displayed for the next Vblank
> > even if it's not showing the last frame from the client. Thoughts?  
> 
> You are correct. This is an existing caveat.

> Solutions to these issue would be good to have, but the timings
> trade-off probably needs investigation and maybe some extensions here
> and there to reach an optimal solution.

Btw. just so it is clear: personally I would consider an application
that renders completely unthrottled and spams the compositor with
frames to be ill-behaving if not outright broken. Wayland has two
different mechanisms for throttling client drawing, the frame callback
maximising the available time to draw and presentation-time extension
to optimise latency to screen.

The major reasons to fortify a compositor by waiting and prioritisation
is to make the compositor more robust in the presence of either abusive
applications (the spamming) or slow applications (take a long time to
render a frame).


Thanks,
pq


pgpPxy0gHn8MH.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Should Weston wait for client buffers to finish rendering?

[Pekka Paalanen]

On Wed, 23 Jan 2019 18:43:52 +
"Singh, Satyeshwar"  wrote:

> Hey guys,
> As you know, Weston doesn't wait for client buffers to finish
> rendering. That is typically left as an exercise for the kernel mode
> graphics driver. I am wondering if anyone knows why this policy
> decision was made? More importantly, is there any harm (or any side
> effect) that I am not thinking of if this policy were to change such
> that the compositor indeed started waiting for client buffers to
> finish rendering first and only used those buffers for composition
> that had finished?

Hi,

the reason is simple: no other option existed when Weston's DRM backend
was written, and no-one has got around to implement anything else yet.

Implicit fencing existed first, because it was required for Xorg and
X11 apps AFAIU. Display/GPU drivers were monolithic, so everything was
driver-internal and implicit fencing was easy to do.

Then came up the systems where the display controller and the GPU are
separate devices under separate drivers, and the need to communicate
between drivers came up, which then lead to the design of dmabufs and
explicit fencing.

Explicit fencing is not mandatory to be able to wait for finish
nowadays, but I think dmabuf might well be.

Making the compositor wait for client buffers to finish rendering will
need some infrastructure work in the compositor, because the compositor
cannot stop to wait, it must keep on running and updating the displays
with the previous client content that is ready.

There is also a timing trade-off to consider. The compositor must start
its own compositing job on the GPU well before vblank if it aims to
make it for the vblank. With implicit fencing policy, a client's GPU
job is allowed to be unfinished at the time the compositor queues the
compositing job, which means the client has more time to finish its GPU
job. OTOH, with a wait-for-finished policy, the client's GPU job must
have finished already at the time the compositor decides to start the
composition for the next vblank.

The timing aspect is fairly complicated, this blog post offers some
examples:
https://ppaalanen.blogspot.com/2015/02/weston-repaint-scheduling.html

The things to consider are the time available for a client to draw, and
the client's latency to output.

> Imagine a benchmark case where the client renders for example 800
> frames and attaches their buffer ids to a surface, the compositor
> uses the last one that came in before its repaint cycle started for
> composition and display on the screen. This buffer may not have been
> rendered by the GPU yet because it is working on previous buffers.
> However, it may not finish before the next Vblank and if it doesn't
> finish, then the compositor's scan out buffer also isn't going to be
> displayed by the kernel driver. If we change the policy for the
> compositor to always use the last finished buffer, then at least the
> compositor's scan out buffer will be displayed for the next Vblank
> even if it's not showing the last frame from the client. Thoughts?

You are correct. This is an existing caveat.

Mind that wait-for-finished policy is not the only factor here in
practise. Another big factor is the task scheduling for the GPU. If the
GPU has a 800 jobs from the client in its queue and then the compositor
adds its compositing job on top as number 801, it is still quite likely
that the GPU will have to crunch through all those 800 before getting
to the compositing job. This is where the GPU driver task scheduling
needs more features: it needs to know that the compositor's job is more
important than the 800 other ones (there are e.g. EGL extensions for
this). Another thing is that instead of the 800 client jobs, there
could be just one client job that takes 2 seconds to finish; in this
case the GPU driver and hardware would need to support pre-emption to
get the compositing job running, which is a relatively new feature.

Solutions to these issue would be good to have, but the timings
trade-off probably needs investigation and maybe some extensions here
and there to reach an optimal solution.


Thanks,
pq


pgpLfuFxVOEQJ.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Should Weston wait for client buffers to finish rendering?

[Pekka Paalanen]

On Wed, 23 Jan 2019 19:28:11 +
"Ucan, Emre (ADITG/ESB)"  wrote:

> Hello Satyeshwar,
> 
> nice to hear from you again (:
> 
> short answer to your question: there is already implementation which is doing 
> what you are asking:
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/32

No, that does not change the policy. It merely hooks up the explicit
acquire fences to do exactly the same the implicit fencing does. It is
for systems and configurations where implicit fencing does not exist.


Thanks,
pq


pgpngfi4PTMZQ.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Fbdev-backend removal from Weston (Re: Upcoming release)

[nerdopolis]

On Wednesday, January 23, 2019 4:09:44 AM EST Pekka Paalanen wrote:
> On Tue, 22 Jan 2019 22:46:02 -0500
> nerdopolis  wrote:
> 
> > On Tuesday, January 22, 2019 9:55:15 AM EST Pekka Paalanen wrote:
> 
> > > 
> > > On Tue, 22 Jan 2019 10:17:32 +0200
> > > Pekka Paalanen  wrote:
> > >   
> > > > Hi,
> > > > 
> > > > do you actually have a use case for that? It's ok if you do, we can
> > > > keep it around for some more, but the simple fact that some hardware
> > > > exists that does not have a working DRM driver is not enough. There
> > > > should be users too.
> > > > 
> > > > The fbdev-backend certainly has its shortcomings, and I don't mean just
> > > > the lack of multi-output or monitor hotplug or GPU acceleration or
> > > > tearing or timings based on nothing but timers; I recall VT-switching
> > > > being broken for years now, and it doesn't (cannot?) use logind to open
> > > > the FB devices. Did I forget some?
> 
> > 
> > Hi
> > 
> > Well, TBH, It's just my quazi-distribution Live CD that I still maintain...
> > It falls back to the Framebuffer on systems (or seats) that don't have 
> > Kernel Mode Setting. The number of users now probably is low...
> 
> Right. Would you be able to do a test? Disable fbdev on your distro and
> see if anyone complains?
> 
TBH, the user base is likely not as high as it was in 2012. It's prime focus
was to allow users to test anything Wayland live. So I don't think that would
be a good way to tell, since now there are other more popular ways people have
been using it now.
> In fact, would be nice if all distributions did that test. I'm not in
> that much hurry to delete the backend yet.
> 
> > VT switching works great. It works without weston-launch, and I can switch 
> > away
> > to a second instance of Weston using the Framebuffer, without them stepping 
> > on
> > each other, and I can switch back to the original one, and it continues 
> > working
> > 
> > I do have to create a udev file that sets
> > SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess"
> > though...
> 
> Yes, that rule or similar is required because logind does not deal fb
> devices IIRC and Weston certainly doesn't ask.
> 
> Are you relying on logind or running Weston privileged to have VT
> switching working?
> 
I am making no changes to logind. I am not running Weston as root. I am not
even granting the plugdev group access to the /dev/fbX devices (It's a "hidden"
boot option, disabled by default). Just systemd-run that starts it as a User
account.
> It's been a long time since I tried VT-switching with fbdev, but it
> didn't work with logind back then:
> https://gitlab.freedesktop.org/wayland/weston/issues/78
> Could it have been fixed in logind instead?
>
Yeah, I wasnt even aware of that one. It was probably logind. Weston is working
fine. I can switch between the framebuffer backed login greeter, and a frame
buffer backed login session, and they don't draw on each other. Weston even
logs when the session becomes active and inactive, so it is aware.

It even works on seats that do NOT have TTYs, since my login manager is
multiseat aware now, I can test that :)
> 
> Thanks,
> pq




___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Fbdev-backend removal from Weston (Re: Upcoming release)

[makepost]

On Tue, 22 Jan 2019 10:17:32 +0200
Pekka Paalanen  wrote:


keep it around for some more, but the simple fact that some hardware
exists that does not have a working DRM driver is not enough


Fbdev worked out of the box on my Bay Trail system, but DRM kept 
freezing where only SysRq helped. It seems an issue in Mesa, downgrade 
to 18.1.9 and exporting WESTON_DISABLE_ATOMIC=y works, but I haven't 
been able to track and report, because nothing weird got in the logs. By 
all means delete this backend if it's tech debt, though some users are 
there yet. Looking forward to new releases so I can unmask 
>=media-video/mpv-0.29, which wants xdg_wm_base.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Should Weston wait for client buffers to finish rendering?

[Ucan, Emre (ADITG/ESB)]

Hello Satyeshwar,

nice to hear from you again (:

short answer to your question: there is already implementation which is doing 
what you are asking:
https://gitlab.freedesktop.org/wayland/weston/merge_requests/32

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937


From: wayland-devel  On Behalf Of 
Singh, Satyeshwar
Sent: Mittwoch, 23. Januar 2019 19:44
To: wayland-devel@lists.freedesktop.org
Subject: Should Weston wait for client buffers to finish rendering?

Hey guys,
As you know, Weston doesn't wait for client buffers to finish rendering. That 
is typically left as an exercise for the kernel mode graphics driver. I am 
wondering if anyone knows why this policy decision was made? More importantly, 
is there any harm (or any side effect) that I am not thinking of if this policy 
were to change such that the compositor indeed started waiting for client 
buffers to finish rendering first and only used those buffers for composition 
that had finished?
Imagine a benchmark case where the client renders for example 800 frames and 
attaches their buffer ids to a surface, the compositor uses the last one that 
came in before its repaint cycle started for composition and display on the 
screen. This buffer may not have been rendered by the GPU yet because it is 
working on previous buffers. However, it may not finish before the next Vblank 
and if it doesn't finish, then the compositor's scan out buffer also isn't 
going to be displayed by the kernel driver. If we change the policy for the 
compositor to always use the last finished buffer, then at least the 
compositor's scan out buffer will be displayed for the next Vblank even if it's 
not showing the last frame from the client.
Thoughts?
-Satyeshwar

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Should Weston wait for client buffers to finish rendering?

[Singh, Satyeshwar]

Hey guys,
As you know, Weston doesn't wait for client buffers to finish rendering. That 
is typically left as an exercise for the kernel mode graphics driver. I am 
wondering if anyone knows why this policy decision was made? More importantly, 
is there any harm (or any side effect) that I am not thinking of if this policy 
were to change such that the compositor indeed started waiting for client 
buffers to finish rendering first and only used those buffers for composition 
that had finished?
Imagine a benchmark case where the client renders for example 800 frames and 
attaches their buffer ids to a surface, the compositor uses the last one that 
came in before its repaint cycle started for composition and display on the 
screen. This buffer may not have been rendered by the GPU yet because it is 
working on previous buffers. However, it may not finish before the next Vblank 
and if it doesn't finish, then the compositor's scan out buffer also isn't 
going to be displayed by the kernel driver. If we change the policy for the 
compositor to always use the last finished buffer, then at least the 
compositor's scan out buffer will be displayed for the next Vblank even if it's 
not showing the last frame from the client.
Thoughts?
-Satyeshwar

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Fbdev-backend removal from Weston (Re: Upcoming release)

[Adam Jackson]

On Tue, 2019-01-22 at 22:46 -0500, nerdopolis wrote:

> Well, TBH, It's just my quazi-distribution Live CD that I still maintain...
> It falls back to the Framebuffer on systems (or seats) that don't have 
> Kernel Mode Setting. The number of users now probably is low...

I think the biggest class of fbdev users on reasonably modern hardware
are people who've said nomodeset to avoid a drm driver bug and so fall
down to efifb. I wonder if it's worth making a trivial efikms driver
for that case.

- ajax
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC] Weston GL shader compilation re-design

[Harish Krupo]

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

Re: [RFC] Weston GL shader compilation re-design

[Pekka Paalanen]

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


pgpEGpL1fPnio.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Fbdev-backend removal from Weston (Re: Upcoming release)

[Pekka Paalanen]

On Tue, 22 Jan 2019 22:46:02 -0500
nerdopolis  wrote:

> On Tuesday, January 22, 2019 9:55:15 AM EST Pekka Paalanen wrote:

> > 
> > On Tue, 22 Jan 2019 10:17:32 +0200
> > Pekka Paalanen  wrote:
> >   
> > > Hi,
> > > 
> > > do you actually have a use case for that? It's ok if you do, we can
> > > keep it around for some more, but the simple fact that some hardware
> > > exists that does not have a working DRM driver is not enough. There
> > > should be users too.
> > > 
> > > The fbdev-backend certainly has its shortcomings, and I don't mean just
> > > the lack of multi-output or monitor hotplug or GPU acceleration or
> > > tearing or timings based on nothing but timers; I recall VT-switching
> > > being broken for years now, and it doesn't (cannot?) use logind to open
> > > the FB devices. Did I forget some?

> 
> Hi
> 
> Well, TBH, It's just my quazi-distribution Live CD that I still maintain...
> It falls back to the Framebuffer on systems (or seats) that don't have 
> Kernel Mode Setting. The number of users now probably is low...

Right. Would you be able to do a test? Disable fbdev on your distro and
see if anyone complains?

In fact, would be nice if all distributions did that test. I'm not in
that much hurry to delete the backend yet.

> VT switching works great. It works without weston-launch, and I can switch 
> away
> to a second instance of Weston using the Framebuffer, without them stepping on
> each other, and I can switch back to the original one, and it continues 
> working
> 
> I do have to create a udev file that sets
> SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess"
> though...

Yes, that rule or similar is required because logind does not deal fb
devices IIRC and Weston certainly doesn't ask.

Are you relying on logind or running Weston privileged to have VT
switching working?

It's been a long time since I tried VT-switching with fbdev, but it
didn't work with logind back then:
https://gitlab.freedesktop.org/wayland/weston/issues/78
Could it have been fixed in logind instead?


Thanks,
pq


pgpofY2eJYo8X.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[RFC] Weston GL shader compilation re-design

[Harish Krupo]

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: Fbdev-backend removal from Weston (Re: Upcoming release)

[nerdopolis]

On Tuesday, January 22, 2019 9:55:15 AM EST Pekka Paalanen wrote:
> Let's make the title more catchy, so that people who care about fbdev
> would notice.
> 
> 
> On Tue, 22 Jan 2019 10:17:32 +0200
> Pekka Paalanen  wrote:
> 
> > On Mon, 21 Jan 2019 20:30:52 -0500
> > nerdopolis  wrote:
> > 
> > > On Friday, January 18, 2019 5:20:40 PM EST Derek Foreman wrote:  
> > > > 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?  
> > 
> > > I feel like the fbdev backend is a good fallback still. Maybe not for 
> > > Virtual
> > > Box anymore, since there is now a driver for it in Mainline (I haven't 
> > > tested
> > > it personally though) ...Currently the Framebuffer backend is the only 
> > > way to
> > > get Weston working on some obscure hardware such as UDL/DisplayLink2 
> > > devices.  
> > 
> > Hi,
> > 
> > do you actually have a use case for that? It's ok if you do, we can
> > keep it around for some more, but the simple fact that some hardware
> > exists that does not have a working DRM driver is not enough. There
> > should be users too.
> > 
> > The fbdev-backend certainly has its shortcomings, and I don't mean just
> > the lack of multi-output or monitor hotplug or GPU acceleration or
> > tearing or timings based on nothing but timers; I recall VT-switching
> > being broken for years now, and it doesn't (cannot?) use logind to open
> > the FB devices. Did I forget some?
> > 
> > 
> > Thanks,
> > pq
> 

Hi

Well, TBH, It's just my quazi-distribution Live CD that I still maintain...
It falls back to the Framebuffer on systems (or seats) that don't have 
Kernel Mode Setting. The number of users now probably is low...

VT switching works great. It works without weston-launch, and I can switch away
to a second instance of Weston using the Framebuffer, without them stepping on
each other, and I can switch back to the original one, and it continues working


I do have to create a udev file that sets
SUBSYSTEM=="graphics", KERNEL=="fb*", TAG+="uaccess"
though...


Thanks


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Fbdev-backend removal from Weston (Re: Upcoming release)

[Pekka Paalanen]

Let's make the title more catchy, so that people who care about fbdev
would notice.


On Tue, 22 Jan 2019 10:17:32 +0200
Pekka Paalanen  wrote:

> On Mon, 21 Jan 2019 20:30:52 -0500
> nerdopolis  wrote:
> 
> > On Friday, January 18, 2019 5:20:40 PM EST Derek Foreman wrote:  
> > > 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?  
> 
> > I feel like the fbdev backend is a good fallback still. Maybe not for 
> > Virtual
> > Box anymore, since there is now a driver for it in Mainline (I haven't 
> > tested
> > it personally though) ...Currently the Framebuffer backend is the only way 
> > to
> > get Weston working on some obscure hardware such as UDL/DisplayLink2 
> > devices.  
> 
> Hi,
> 
> do you actually have a use case for that? It's ok if you do, we can
> keep it around for some more, but the simple fact that some hardware
> exists that does not have a working DRM driver is not enough. There
> should be users too.
> 
> The fbdev-backend certainly has its shortcomings, and I don't mean just
> the lack of multi-output or monitor hotplug or GPU acceleration or
> tearing or timings based on nothing but timers; I recall VT-switching
> being broken for years now, and it doesn't (cannot?) use logind to open
> the FB devices. Did I forget some?
> 
> 
> Thanks,
> pq



pgp6Onkuf6qm9.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

On Fri, 18 Jan 2019 09:05:53 +0530
"Sharma, Shashank"  wrote:

> On 1/17/2019 5:33 PM, Pekka Paalanen wrote:
> > On Wed, 16 Jan 2019 09:25:06 +0530
> > "Sharma, Shashank"  wrote:
> >  
> >> On 1/14/2019 6:51 PM, Pekka Paalanen wrote:  
> >>> On Thu, 10 Jan 2019 20:32:18 +0530
> >>> "Sharma, Shashank"  wrote:
> >>>  
> >>>> 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.  

> > In summary, rather than dynamically allow or not allow, a compositor
> > needs to live by its promise on what works. It cannot pull the rug from
> > under a client by suddenly hiding the window or showing it corrupted.
> > That is the baseline in behaviour.  
> Makes a lot of sense, and sounds like a stable design too.
> As per this design policy, while coming up, compositor can analyze the 
> static environment conditions like:
> - HW support for HDR
> - Kernel support for HDR
> 
> and based on these two it can decide to advertise the HDR capabilities 
> via the protocol, and once it does so, it has to make sure that it lives 
> up-to expectation.
> Now, the only variable in the environment is a hot-pluggable monitor, 
> which might/might not support HDR playback, and that needs to be handled 
> at runtime by:
> - Doing H2S tone mapping, if monitor can't support HDR playback.
> - and REC2020->REC709 conversion using CSC.
> - using GL blending as fallback if we are not able to prepare a plane 
> only state.
> 
> Does it seem like correct interpretation of your suggestions ?

Yes, it does.

Mind, in the future Weston may very well also support GPU hotplug for
additional sinks, which means that the kernel and graphics card support
becomes variable as well. But handling that is no different from
handling monitor variability.

> > Then we can have some mechanisms in place to inform clients about
> > changed conditions, like sending HDR content becomes useful or stops
> > being useful. The first mechanism here is the wl_surface.enter/leave
> > events: if the wl_surface enters the first HDR output, or leaves the
> > last HDR output, the client will know and may adapt if it wants to.  
> Again, sounds like a good idea.

As discussed with Graeme, the mechanism here might well be the
"prioritised output" protocol yet to be invented.


> > This means that you need to avoid interface name conflicts between
> > weston and wayland-protocols extensions.  
> Got it, I think you are suggesting something like the way how we 
> implemented aspect-ratio protocol in weston.

Well, aspect ratio did not have any protocol in the end. :-)


Thanks,
pq


pgp9qrDzyR38P.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

is no
> easy means of creating display profiles to populate it with. So in
> terms of practical implementation I see them going hand in hand.

They may go hand-in-hand in practise, but protocol-wise I still see
them as two completely orthogonal features, and we need to split the
work into manageable chunks anyway.

Surely the color characterisation of a monitor is not specific to a
window system? While we still don't have a good solution to
measurements in Wayland, people can measure their monitors on Xorg, or
even Windows, I hope. Or even better: using a measuring tool running
directly on DRM KMS, which ensures the tool gets absolute control over
the display hardware. DRM Leases could make such a tool usable under a
Wayland compositor, too, so you can have a control UI window as a
Wayland window on another output. People can take advantage of color
managed output already while the community figures out a good way to
handle measuring.

As an example of orthogonality, I would like to point to the new
touchscreen calibration tool for Weston. Commit adding the new tool
lists the benefits it has over the old calibration tool that was using
the usual input interfaces in Wayland:
https://gitlab.freedesktop.org/wayland/weston/commit/b79dead1dded6744d251da5357e14c83b91cef32

This commit added the protocol extension:
https://gitlab.freedesktop.org/wayland/weston/commit/999876a8f98791f92badd89b5b62481bf6dfcb4a

The reason the extension is specific to Weston is that there was no
interest in making it a standard, no-one else saw the need to calibrate
touchscreen input. It could still be standardised if the interest
arises.

Likewise, measuring the color characteristics of a monitor will likely
require a notion of intent to a Wayland compositor. Not only one wants
to be absolutely sure the compositor is not mangling the pixel data,
the calibration pattern must be shown on the correct monitor in the
correct place, even if some monitors were cloned. This is not usually
possible with the public desktop set of Wayland extensions. Touchscreen
calibration had the same problem with choosing the output and
positioning the pattern on screen.


Thanks,
pq


pgpCaUrgUzkGu.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Kai-Uwe]

Am 18.01.19 um 09:08 schrieb Graeme Gill:> Maybe rendering specifically
for one output is sufficient
> as long as the secondary displays (however that is determined!) look
> OK with a fallback conversion by the compositor.

Currently the first or main monitor is the primary rendering target. As
long as it is switchable, that's fine with me.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Graeme Gill]

Sharma, Shashank wrote:

Hi,

> Yes, this is very accurate. We are planning to add a protocol extension, 
> which will allow
> a client to pass the buffers colorspace information to the compositor. And 
> compositor
> already has HW's color capabilities (drm properties per plane and CRTC), and 
> monitor color
> capabilities (EDID). So if compositor gets all of this, with some good 
> policies, it might
> be able to take call on colorspace accurately.

my impression from past feedback is that EDID display characterization as a rule
is not to be relied on, at least not if any degree of accuracy is desired. Maybe
the manufacturers have got better.

But I can sympathize with the desire of not getting bogged down in
color management stuff if you are just trying to get something
vaguely reasonable displayed on HDR.

> Correct, in fact, we would be using these same CRTC channels to apply the 
> EOTFs. If we go
> through the REC2020/2023 spec carefully, we realize that EOTF/OETF curves are 
> nothing but
> gamma/degamma correction curves for HDR monitors while they are displaying a 
> much wider
> gamut, like BT2020 or DCI-P3. I had written one drm-compositor based 
> implementation of
> sample color management using these CRTC/Plane color properties being exposed 
> by DRM, for
> accurate blending, but now I want to go through and understand Niels's color 
> management
> solution first.

Sure. If you just take the HDR monitors as being nominally HDR10 or similar, 
then you can
do a by-the-spec conversion and get something working.

Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Graeme Gill]

Adam Jackson wrote:

Hi,

> This isn't necessarily true. The server is free to just draw a black
> rectangle (or nothing) instead if the image doesn't match the target
> colorspace. If you want to handle the case of cloned outputs or
> crossing output borders, let the client attach one image per output
> colorspace if it wants, and let the server send the client events to
> indicate when it should start or stop drawing to a particular
> colorspace. You need that complexity in the client's renderer anyway,
> why add it to the server's?

yes, that crossed my mind. I'm wondering if in practice that is
overkill though. Maybe rendering specifically for one output is sufficient
as long as the secondary displays (however that is determined!) look
OK with a fallback conversion by the compositor. Multiple optimized
renderings per surface could always be added to the hybrid/fallback scheme
at a latter point ?

Cheers,
Graeme Gill.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Graeme Gill]

Pekka Paalanen wrote:

Hi,

> If a wl_surface straddles multiple outputs simultaneously, then
> wl_surface.enter/leave events indicate the surface being on all those
> outputs at the same time. The client is expected to take all the
> entered outputs into consideration when it chooses how to render its
> image. For HiDPI, this usually means taking the maximum output scale
> from that set of outputs. The compositor will then automatically
> (down)scale for the other outputs accordingly.

right, I was guessing this is how it works. So an obvious heuristic
for HiDPI is to render to the highest density output, on the basis
that the compositor down-sampling is the least detrimental to quality.

A wrinkle in using the same idea for Color Management is that such
a heuristic may not be as clear. For the case of a window being moved from
one output to another, then either a last to leave or first to enter
might make sense. If (as I presume) surfaces are multiply mapped
to achieve mirroring or similar (picture in picture ?), then I'm not so
sure how the most important display can be determined heuristically.
Even in the case of a projector, I could imagine under some circumstances
the projected color accuracy is secondary, and other circumstances it is
most important.

> This scheme also means that the compositor does not necessarily need to
> wait for a client to render when the outputs suddenly change. It knows
> how to transform the existing image for new outputs already. The visual
> quality may jump afterwards when the client catches up, but there is no
> window blinking in and out of existence.

Right, I took this as a particular design aim in Wayland.

> Yes and no. Yes, we do and should let clients know what kind of outputs
> their contents will be shown on. However, we will in any case need the
> compositor to be able to do the full and correct conversion from what
> ever the client has submitted to what is correct for a specific output,
> because nothing guarantees that those two would always match.

I don't think that's technically possible, because it's analogous to
Wayland taking on the rendering. But I also don't think it's a necessary
either, because as long as the client can do it's rendering for the
output that is most quality sensitive, then it's enough that the compositor
can do a less perfect transform between the display or colorspace that was
rendered to and the display it is actually appearing on. This is a much simpler
proposition than full general color management since you can assume that
all buffers are display-like and only have 3 channels, and that simple
to define color transform intents will be sufficient. Similarly to the HiDPI
case, the visual quality may jump slightly if the surface is re-rendered
for its actual output, but on most displays the difference shouldn't terribly
obvious unless you were looking for it.

Some nice properties of this approach are that it provides the usual
mechanism for an application (like a Color Management profiling app.)
to set device values using the null transform trick (setting source
colorspace the same as destination. If the two profiles are the same,
color conversion should be skipped by the CMM/compositor.)
A second property is that it would be possible to set a default
source colorspace for clients that don't know about color management
(i.e. sRGB). This allows a "color managed desktop" using existing window
managers and applications, solving the problems of using wide gamut or HDR
displays running in their full mode.

> This makes no use of the monitor HDR capability, but it would start
> with the most important feature: backward compatibility. Adding the
> Wayland protocol to allow clients to reasonably produce and submit HDR
> content could come after this as a next phase.

Yes, that would be a good thing to get out of it.

> I'm not sure I understand what you mean. Above you seemed to agree with
> this. Maybe I should emphasise the "if it has to"? That is, when for
> whatever reason, the client provided content is not directly suitable
> for the output it will be displayed on.

OK, a detail I seem to be having difficulty conveying is the
difference between doing a bulk conversion between two colorspaces,
and rendering in a color aware fashion. Example :- consider rendering
a document stored in a sophisticated page description language
such as PDF, PS or XPF. These are color aware formats, and in general
pages may be composed of multiple different graphic elements that can
have their color described in a multitude of different ways. Some may
be in device dependent spaces such as RGB. Some may be in CMYK.
Some may be in device independent CIE based spaces such as L*a*b*.
Some may be spot colors. Each may be specified to be rendered with
specific color transform intents. For instance, a screen capture image may
be specified in RGB and rendered with a Relative Colorimetric Intent,
where the white points are matched and colors otherwise directly 

Re: HDR support in Wayland/Weston

[Sharma, Shashank]

Regards

Shashank


On 1/17/2019 5:33 PM, Pekka Paalanen wrote:

On Wed, 16 Jan 2019 09:25:06 +0530
"Sharma, Shashank"  wrote:


On 1/14/2019 6:51 PM, Pekka Paalanen wrote:

On Thu, 10 Jan 2019 20:32:18 +0530
"Sharma, Shashank"  wrote:


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.

*snip*


I understand your aim is to leverage display hardware capabilities to
the fullest, but we must also consider hardware that lacks some or all
of the conversion/mapping/other features while the monitor is well
HDR-capable. We also need to consider what happens when a monitor is
not HDR-capable or is somehow lacking. OTOH, whether a compositor
implements HDR support at all would be obvious in the advertised
Wayland globals and pixel formats.

Very valid point. We have given good thoughts on how to handle such
scenarios when we are getting into, and we can come-up with some kind of
compositor policies which will decide if HDR video playback should be
allowed or not, depending on the combination of Content type, SW
stack(compositor and kernel), HW capabilities and connected Monitor
capabilities. A sample such policy may look like (also attached as txt
file, just in case if this table gets distorted):

++--+
|Content |SW (C|K)|HW |Monitor   | HDR Playback

*clip*

Talking in terms of "allowed" and "not allowed" sounds very much like
we would be needing "complicated" Wayland protocol to let applications
fail gracefully at runtime, letting them know dynamically when things
would work or not work. I believe we could do much simpler in protocol
terms as follows:

Does a compositor advertise HDR support extensions at all?

- This would depend on the compositor implementation obviously, cannot
   advertise anything without.

- Optionally, it could depend on the graphics card hardware/driver
   capabilities: if there is no card that could support HDR, then there
   is no reason advertise HDR support through Wayland, because it would
   always fall back to conversion to SDR. However, note that GPU hotplug
   might be a thing, which might bring HDR support later at runtime.

- Third, optionally again, a compositor might choose to not advertise
   HDR support if it knows it will never had a HDR-capable monitor
   attached. This is much longer stretch, and probably only for embedded
   devices you cannot plug arbitrary monitors to.

Once the Wayland HDR-related extensions have been advertised to clients
at runtime, taking them away will be hard. You may want to consider to
never revoke the extension interfaces if they have once been published
in the lifetime of a compositor instance, because revoking Wayland
globals has some caveats, mostly around clients still using HDR
extensions until they actually notice the compositor wants to redact
them. It can be made to work, but I'm not sure what the benefit would
be.

So, once a compositor advertises the extensions, they have to keep on
working at all times. Specifically this means, that if a client has
submitted a frame in HDR, and the compositor suddenly loses the ability
to physically display HDR, e.g. the only HDR monitor gets unplugged and
only SDR monitors remain, the compositor must still be able to show the
window that has HDR content lingering. So converting HDR to SDR
on-demand is a mandatory feature.

The allowed vs. not allowed is only applicable with respect to what
capabilities the compositor has advertised.

A client is not "allowed" to submit HDR content if the compositor does
not expose the Wayland extensions. Actually this is not about allowing,
but being able to submit HDR content at all: if the interfaces are not
advertised, a client simply has no interface to poke at.

Pixel formats, color spaces, and so on are more interesting. The
compositor should advertise what it supports by enumerating them
explicitly or saying what description formats it supports. Then a
client cannot use anything outside of those; if it attempts to, that
will be a fatal protocol error, not a recoverable failure.

If a client does everything according to what a compositor advertises,
it must "work": the compositor must be able to consume the client
content regardless of what will happen next, e.g. with monitor
hot-unplug, or scenegraph changing such that overlay plane is no longer
usable. This is why the fallback path through GL-renderer must exist,
and it must be able to do HDR->SDR mapping, and so on.

In summary, rather than dynamically allow or not allow, a compositor
needs to live by its promise on what works. It cannot pull the rug from
under a client by suddenly hiding the window or showing it corrupted.
That is the baseline in behaviour.

Makes a lot of sense, and sounds like a stable 

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

On Tue, 15 Jan 2019 14:14:53 -0500
Adam Jackson  wrote:

> On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote:
> > On Tue, 15 Jan 2019 13:47:07 +1100
> > Graeme Gill  wrote:
> >   
> > > If done in the composer, it would need to render the graphic elements to
> > > the output DPI / convert the source colorspace to the output colorspace.
> > > But the composer would need the code to do rendering / convert colorspaces
> > > (as well as being told what the graphic elements / source colorspace is),
> > > and this is not the role Wayland has - that's the responsibility of the
> > > client, so instead Wayland makes it possible for the client to know what 
> > > DPI
> > > it is rendering to. The analogous facility for CM is for the client to 
> > > know
> > > what output colorspace it is rendering for.  
> > 
> > Yes and no. Yes, we do and should let clients know what kind of outputs
> > their contents will be shown on. However, we will in any case need the
> > compositor to be able to do the full and correct conversion from what
> > ever the client has submitted to what is correct for a specific output,
> > because nothing guarantees that those two would always match.  
> 
> This isn't necessarily true. The server is free to just draw a black
> rectangle (or nothing) instead if the image doesn't match the target
> colorspace.

Hi Adam,

in my opinion it is not acceptable in a Wayland compositor.

Wayland protocol does not say anything about the final visual, so
showing a corrupted window (black, invisible, whatever) is not a
protocol violation per se, but I still think it would be a buggy
compositor if I can observe it.

At least Weston should do better. OTOH, a specialised compositor running
in a fixed environment and very specific use cases might be able to
manage with showing black, because no intended use case would make the
automatic conversion necessary. The protocol shouldn't care, both
implementations should be possible.

If no-one ever triggers a bug, does the bug need fixing?

> If you want to handle the case of cloned outputs or
> crossing output borders, let the client attach one image per output
> colorspace if it wants, and let the server send the client events to
> indicate when it should start or stop drawing to a particular
> colorspace. You need that complexity in the client's renderer anyway,
> why add it to the server's?

We could do that, but then it would not allow to blend different
windows correctly together. It would only work for completely opaque
windows.

The increase in memory usage would also be significant. The decrease in
overall system performance might be too, though that is not obvious.

> > One wl_surface on multiple outputs is an obvious case where one buffer
> > rendered by a client cannot match all the outputs it is shown on. The
> > other case is transitions between outputs, where we cannot have the
> > compositor wait for the client to re-draw with new color parameters.  
> 
> Honestly I think of this as an implementation issue?

Yes, it very much is an implementation issue.

> If we take the
> above multiple-images approach, then if it's my compositor I just omit
> drawing actors onto any output where there isn't an image for that
> colorspace, because I am comfortable saying any further latency is the
> client's renderer's problem. Someone else's compositor might try to
> bend the existing image to the output colorspace until the client has
> caught up, believing close-but-wrong color is better than visible
> absence of color. I could see an argument for either implementation
> depending on the environment, and I don't really see why the protocol
> spec should require one or the other.

That is correct.

The protocol spec will not require one way or another. The protocol
spec only needs to enable both ways.


Thanks,
pq


pgplxe9mbzLQi.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

On Tue, 15 Jan 2019 13:19:00 +0100
Niels Ole Salscheider  wrote:

> Am Dienstag, 15. Januar 2019, 10:30:14 CET schrieb Pekka Paalanen:

> > Yes and no. Yes, we do and should let clients know what kind of outputs
> > their contents will be shown on. However, we will in any case need the
> > compositor to be able to do the full and correct conversion from what
> > ever the client has submitted to what is correct for a specific output,
> > because nothing guarantees that those two would always match.
> > 
> > One wl_surface on multiple outputs is an obvious case where one buffer
> > rendered by a client cannot match all the outputs it is shown on. The
> > other case is transitions between outputs, where we cannot have the
> > compositor wait for the client to re-draw with new color parameters.  
> 
> I think the last proposal of a color management protocol that we discussed 
> does that. It contains the device link profiles and it also allows the client 
> to query the profile of wl_outputs. With that, an application can display 
> accurate colors in nearly every situation, even on multiple screens 
> simultaneously. But still the compositor can do it's best to provide a good 
> output in some corner cases (e. g. when a new screen is activated and the 
> application has not rendered a new frame yet). Once the application reacts to 
> that change the output will be perfect again.

Sounds good! Sorry, I have not had a chance to refresh my memory on that
proposal, but I have high hopes that it will fit the HDR use case
nicely.


Thanks,
pq


pgpGHijxErVWI.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

On Wed, 16 Jan 2019 09:25:06 +0530
"Sharma, Shashank"  wrote:

> On 1/14/2019 6:51 PM, Pekka Paalanen wrote:
> > On Thu, 10 Jan 2019 20:32:18 +0530
> > "Sharma, Shashank"  wrote:
> >
> >> 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.

*snip*

> > I understand your aim is to leverage display hardware capabilities to
> > the fullest, but we must also consider hardware that lacks some or all
> > of the conversion/mapping/other features while the monitor is well
> > HDR-capable. We also need to consider what happens when a monitor is
> > not HDR-capable or is somehow lacking. OTOH, whether a compositor
> > implements HDR support at all would be obvious in the advertised
> > Wayland globals and pixel formats.

> Very valid point. We have given good thoughts on how to handle such 
> scenarios when we are getting into, and we can come-up with some kind of 
> compositor policies which will decide if HDR video playback should be 
> allowed or not, depending on the combination of Content type, SW 
> stack(compositor and kernel), HW capabilities and connected Monitor 
> capabilities. A sample such policy may look like (also attached as txt 
> file, just in case if this table gets distorted):
> 
> ++--+
> |Content |SW (C|K)|HW |Monitor   | HDR Playback 

*clip*

Talking in terms of "allowed" and "not allowed" sounds very much like
we would be needing "complicated" Wayland protocol to let applications
fail gracefully at runtime, letting them know dynamically when things
would work or not work. I believe we could do much simpler in protocol
terms as follows:

Does a compositor advertise HDR support extensions at all?

- This would depend on the compositor implementation obviously, cannot
  advertise anything without.

- Optionally, it could depend on the graphics card hardware/driver
  capabilities: if there is no card that could support HDR, then there
  is no reason advertise HDR support through Wayland, because it would
  always fall back to conversion to SDR. However, note that GPU hotplug
  might be a thing, which might bring HDR support later at runtime.

- Third, optionally again, a compositor might choose to not advertise
  HDR support if it knows it will never had a HDR-capable monitor
  attached. This is much longer stretch, and probably only for embedded
  devices you cannot plug arbitrary monitors to.

Once the Wayland HDR-related extensions have been advertised to clients
at runtime, taking them away will be hard. You may want to consider to
never revoke the extension interfaces if they have once been published
in the lifetime of a compositor instance, because revoking Wayland
globals has some caveats, mostly around clients still using HDR
extensions until they actually notice the compositor wants to redact
them. It can be made to work, but I'm not sure what the benefit would
be.

So, once a compositor advertises the extensions, they have to keep on
working at all times. Specifically this means, that if a client has
submitted a frame in HDR, and the compositor suddenly loses the ability
to physically display HDR, e.g. the only HDR monitor gets unplugged and
only SDR monitors remain, the compositor must still be able to show the
window that has HDR content lingering. So converting HDR to SDR
on-demand is a mandatory feature.

The allowed vs. not allowed is only applicable with respect to what
capabilities the compositor has advertised.

A client is not "allowed" to submit HDR content if the compositor does
not expose the Wayland extensions. Actually this is not about allowing,
but being able to submit HDR content at all: if the interfaces are not
advertised, a client simply has no interface to poke at.

Pixel formats, color spaces, and so on are more interesting. The
compositor should advertise what it supports by enumerating them
explicitly or saying what description formats it supports. Then a
client cannot use anything outside of those; if it attempts to, that
will be a fatal protocol error, not a recoverable failure.

If a client does everything according to what a compositor advertises,
it must "work": the compositor must be able to consume the client
content regardless of what will happen next, e.g. with monitor
hot-unplug, or scenegraph changing such that overlay plane is no longer
usable. This is why the fallback path through GL-renderer must exist,
and it must be able to do HDR->SDR mapping, and so on.

In summary, rather than dynamically allow or not allow, a compositor
needs to live by its promise on what works. It cannot pull the rug from

Re: HDR support in Wayland/Weston

[Harish Krupo]

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: HDR support in Wayland/Weston

[Arnaud Vrac]

On Thu, Jan 17, 2019 at 4:26 AM Sharma, Shashank
 wrote:
>
> Hello Arnaud
>
> Thanks for your comments, mine inline.
>
> Regards
> Shashank
> On 1/17/2019 6:38 AM, Arnaud Vrac wrote:
> > On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
> >  wrote:
> >> 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 wil

Re: HDR support in Wayland/Weston

[Sharma, Shashank]

Hello Arnaud

Thanks for your comments, mine inline.

Regards
Shashank
On 1/17/2019 6:38 AM, Arnaud Vrac wrote:

On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
 wrote:

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 same can be found here: 
https://patchwork.freedesktop.org/series/25091/
 - And they will ever live happily after :).

Please provide inputs, feedbacks and suggestions for this design and plan, so 
that we can improve out half cooked solution, and start sending the patches.

  +--+ +---+
  | SDR Buffer subtitles   | HDR Buffer video
  | (REC  709 colorsp) | (REC 2020 colorsp |
  |  | |   |
  +---+--+ +---+---+
  ||
  ||
  ||
   +--v---v+
 +--+
   |   Compositor: v   |
 | LibVA|
   |   - assigns views to overlays 
+-> Tone mapping |
   |   - prepare plane/CRTC color properties   
<-+ SDR to HDR   |
   | for linear blending in display|   

Re: HDR support in Wayland/Weston

[Arnaud Vrac]

On Thu, Jan 10, 2019 at 4:02 PM Sharma, Shashank
 wrote:
>
> 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 same can be found here: 
> https://patchwork.freedesktop.org/series/25091/
> - And they will ever live happily after :).
>
> Please provide inputs, feedbacks and suggestions for this design and plan, so 
> that we can improve out half cooked solution, and start sending the patches.
>
>  +--+ +---+
>  | SDR Buffer subtitles   | HDR Buffer video
>  | (REC  709 colorsp) | (REC 2020 colorsp |
>  |  | |   |
>  +---+--+ +---+---+
>  ||
>  ||
>  ||
>   +--v---v+   
>   +--+
>   |   Compositor: v   |   
>   | LibVA|
&g

Re: HDR support in Wayland/Weston

[Sharma, Shashank]

Hello Graeme,

Thanks for your inputs and comment, please find mine inline.

Regards
Shashank
On 1/11/2019 12:55 PM, Graeme Gill wrote:

Sharma, Shashank wrote:

Hi,

While I'm sure you could hard code various color space assumptions into
such an implementation (and perhaps this is a pretty reasonable way
of doing a proof of concept), it's not a good long term solution,
and could end up being something of a millstone. What's missing
is any serous Color Management in Wayland. It's a bigger project
to fix that, but HDR would then be able to slot into a much more usable
framework.
I agree, honestly, HDR might be the biggest consumer of color 
management. We can very well use this stack to drive color management 
design. But the only worry is, when to target too big and too generic, 
the actual purpose gets diluted and we get stuck into long chain of mail 
communication. So probably the most important thing for us, as a team, 
would be to break this implementation into small measurable steps which 
slowly targets respective areas of Weston development, keeping the end 
goal alive.

- HDR content/buffers are composed in REC2020 colorspace, with bit depth 
10/12/16 BPC.
Some of the popular formats are P010,P012,P016.

While REC2020 based HDR colorspaces are very popular, they aren't the only ones 
out there.
Agree. My sole purpose of proposing this design was to talk to people, 
and come up with a small, scalable target use case, which we can slowly 
expand and shape into a bigger, more generic framework, over the period 
of time and maturity. So the target was to start with one of the broadly 
used cases, and try to expand this range, into all possible 
formats/cases without regressing into existing framework.

- Normal SRGB buffers are composed in SRGB color space following REC709 
specifications.

As far as I'm aware (I haven't been closely monitoring this mailing
list since the last rather long and unsatisfactory discussion about color
management), Wayland works in display dependent colorspace, since there
is no facility for it to know how to convert from anything else to the
display space (i.e. no knowledge of display profiles so it doesn't
know what sRGB is). In all other computer graphic display systems, it's
up to the client to be informed about each display colorspace is, and
to do color conversion to the display space either itself, or by using
operating system libraries. The operating system provides the display
profile information to allow this. As far as I was informed, Wayland
is architected in such a way that this is not possible, since clients
have no knowledge of which display the pixels they send will end up on.
Yes, this is very accurate. We are planning to add a protocol extension, 
which will allow a client to pass the buffers colorspace information to 
the compositor. And compositor already has HW's color capabilities (drm 
properties per plane and CRTC), and monitor color capabilities (EDID). 
So if compositor gets all of this, with some good policies, it might be 
able to take call on colorspace accurately.


Also, only from HDR implementation point-of-view, we need not to really 
know, that which REC709 implementation is this buffer actually. We just 
need to know if this is a BT2020 buffer or not, so that we an scale 
up/down the color gamut, for a proper blending scenario. So again, 
strictly for HDR playback scenario, a non-2020 buffer can be considered 
as 709 buffer, and its almost safe.


But if we want to provide a proper and accurate color management 
solution, we definitely need to know more about the buffer's 
color-space, than if its 2020 or not.

Also note that while the use of an intermediate compositing space is
essential when combining different colorspace sources together, it's
not desirable in other situations where maximum fidelity and
gamut are desired i.e. Photography. (The double conversions are a
possible accuracy loss, and it makes it very difficult to
achieve good gamut mapping from large gamut sources.)
Very valid point, and that's why I was incline towards using the display 
HW's capabilities, because modern day HWs are investing well on the 
color pipeline to handle cases like HDR. I guess once we have a mature 
basic stack working, we can think of adding something like a uses's 
preference, which could be another entry in our blending decision making 
inputs.

- 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)

Is that something that Wayland should really know about though ?
i.e. shouldn't that be an application issue, where Wayland provides
the necessary mechanisms to achieve correct composition ?
(Or in fact is that what you are suggesting ?)
Not really, I was in favo

Re: HDR support in Wayland/Weston

[Sharma, Shashank]

Hello Pekka,

Thanks a lot for your comments, and inputs on design, stability and 
general accessibility across all platforms.

Please find my comments, inline.

Regards
Shashank
On 1/14/2019 6:51 PM, Pekka Paalanen wrote:

On Thu, 10 Jan 2019 20:32:18 +0530
"Sharma, Shashank"  wrote:


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 same can be found here:
https://patchwork.freedesktop.org/series/25091/
  - And they will ever live happily after :).

Please provide inputs, feedbacks and suggestions for this design and
plan, so that we can improve out half cooked solution, and start sending
the patches.

Hi Shashank,

this is a major feature that would be awesome to have in Weston, but
it's also a big effort to design, implement, and maintain. To ease the
maintenance, we will need some serious work on the test suite, which
currently cannot even run the GL-renderer.
I agree, Weston's stability and maintenance must be high priority. 
That's why I was thinking that instead of enabling such a huge feature 
in a single shot, and trying to cover all possible cases and 
combinations, we can split it into small modular subset of features, in 
form of small patch series, review it well, and add it slowly in the 
mainstream with proper precaution.


These subsets could be ( just example)
- enabling single HDR view (like a movie playback), in fullscreen mode, 
targeting only one target colorspace (say BT2020) and one type of HDR 
metadata (say Static HDR metadata, PQ ST 2084 EOTF, HDR 10 type)

Re: HDR support in Wayland/Weston

[Adam Jackson]

On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote:
> On Tue, 15 Jan 2019 13:47:07 +1100
> Graeme Gill  wrote:
> 
> > If done in the composer, it would need to render the graphic elements to
> > the output DPI / convert the source colorspace to the output colorspace.
> > But the composer would need the code to do rendering / convert colorspaces
> > (as well as being told what the graphic elements / source colorspace is),
> > and this is not the role Wayland has - that's the responsibility of the
> > client, so instead Wayland makes it possible for the client to know what DPI
> > it is rendering to. The analogous facility for CM is for the client to know
> > what output colorspace it is rendering for.
> 
> Yes and no. Yes, we do and should let clients know what kind of outputs
> their contents will be shown on. However, we will in any case need the
> compositor to be able to do the full and correct conversion from what
> ever the client has submitted to what is correct for a specific output,
> because nothing guarantees that those two would always match.

This isn't necessarily true. The server is free to just draw a black
rectangle (or nothing) instead if the image doesn't match the target
colorspace. If you want to handle the case of cloned outputs or
crossing output borders, let the client attach one image per output
colorspace if it wants, and let the server send the client events to
indicate when it should start or stop drawing to a particular
colorspace. You need that complexity in the client's renderer anyway,
why add it to the server's?

> One wl_surface on multiple outputs is an obvious case where one buffer
> rendered by a client cannot match all the outputs it is shown on. The
> other case is transitions between outputs, where we cannot have the
> compositor wait for the client to re-draw with new color parameters.

Honestly I think of this as an implementation issue? If we take the
above multiple-images approach, then if it's my compositor I just omit
drawing actors onto any output where there isn't an image for that
colorspace, because I am comfortable saying any further latency is the
client's renderer's problem. Someone else's compositor might try to
bend the existing image to the output colorspace until the client has
caught up, believing close-but-wrong color is better than visible
absence of color. I could see an argument for either implementation
depending on the environment, and I don't really see why the protocol
spec should require one or the other.

- ajax
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Niels Ole Salscheider]

r cases (e. g. when a new screen is activated and the 
application has not rendered a new frame yet). Once the application reacts to 
that change the output will be perfect again.

> > The clean/simplest approach to HDR is to treat it as just another output
> > colorspace, where it is up to the application to render the color
> > it intends to display, and the Wayland compositor is compositing
> > everything
> > for that output in that HDR colorspace.
> 
> Agreed.
> 
> > Now practically speaking this would assume that all Wayland clients
> > connected to an HDR display in HDR mode are CM/HDR aware, which is rather
> > unlikely. So some backward compatibility modes might be highly desirable
> > (I have some thoughts on that), but in any case, it would also help the
> > quality of such backward compatibility _and_ compositing (i.e. linear
> > light compositing option), if Wayland at least had access to the output
> > color profiles. So there is a lot of advantage in Wayland providing the
> > registry/API of output color profiles both for itself, and clients.
> 
> That backward compatibility / fallback is an integral part of the image
> transformations the compositor must be able to do in any case. So yes,
> I agree.
> 
> For instance, the whole HDR support project could start with:
> - letting Weston recognize HDR-capable monitors and fetch their info
> - turn on HDR video mode
> - patch GL-renderer to convert all old (sRGB or whatever default when
>   nothing is said about color space and other details) content to be
>   suitable for HDR display
> This makes no use of the monitor HDR capability, but it would start
> with the most important feature: backward compatibility. Adding the
> Wayland protocol to allow clients to reasonably produce and submit HDR
> content could come after this as a next phase.
> 
> What details we actually need to expose via Wayland about the outputs
> or compositor blending spaces or something else I will gladly leave to
> those who actually know about color management.
> 
> > > Wayland and apps need to provide the compositor all the necessary
> > > information for the compositor to do all the conversions, mapping and
> > > blending correctly, if it has to.
> > 
> > And perhaps it shouldn't have to.
> 
> I'm not sure I understand what you mean. Above you seemed to agree with
> this. Maybe I should emphasise the "if it has to"? That is, when for
> whatever reason, the client provided content is not directly suitable
> for the output it will be displayed on.
> 
> > > This is because an application will provide only one image for a
> > > wl_surface, and the compositor may show that on any number of any kind
> > > of outputs at once.
> > 
> > That's a big problem. That assumes either that all displays are
> > interchangeable at the pixel level (they are not - they have different
> > DPI and Colorspaces/Gamut/HDR capability), or that Wayland has to know
> > how to re-render to accommodate those difference (and Wayland doesn't do
> > rendering, and may not want to include Colorspace conversion machinery or
> > HDR colorspace/conversion machinery).
> It will be the compositor that will automatically convert images to
> whatever output they will be displayed on, just like the automatic
> scaling with HiDPI. Wayland only needs to relay enough information that
> the compositor can do that when necessary.
> 
> > > Nothing prevents adding more protocol to give apps more hints to behave
> > > more optimally wrt. to the compositor's internal pipeline.
> > 
> > There's a difference between hints that help speed and quality but
> > still burden the compositor with doing display dependent conversions,
> > and an approach that removes hat burden completely to the client when
> > it does the rendering.
> 
> That burden cannot be eliminated in a general desktop environment.
> There will always be situations where the compositor has to convert,
> because a client has not or could not provide directly suitable content.
> 
> If we were to limit ourselves to narrow use cases outside of a generic
> desktop system, then eliminating that burden might be possible. For
> devices like TVs that would be highly desirable even. In the closed
> system of a TV, all apps and all outputs are known beforehand, so the
> operating system can simply avoid the general anything-to-anything
> situations. Desktop systems are not that limited.
> 
> Weston needs to have all those correct conversions implemented. If
> Weston gets used in an environment where those conversions are not
> necessary, then Weston wil

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

for itself, and clients.

That backward compatibility / fallback is an integral part of the image
transformations the compositor must be able to do in any case. So yes,
I agree.

For instance, the whole HDR support project could start with:
- letting Weston recognize HDR-capable monitors and fetch their info
- turn on HDR video mode
- patch GL-renderer to convert all old (sRGB or whatever default when
  nothing is said about color space and other details) content to be
  suitable for HDR display
This makes no use of the monitor HDR capability, but it would start
with the most important feature: backward compatibility. Adding the
Wayland protocol to allow clients to reasonably produce and submit HDR
content could come after this as a next phase.

What details we actually need to expose via Wayland about the outputs
or compositor blending spaces or something else I will gladly leave to
those who actually know about color management.

> > Wayland and apps need to provide the compositor all the necessary
> > information for the compositor to do all the conversions, mapping and
> > blending correctly, if it has to.  
> 
> And perhaps it shouldn't have to.

I'm not sure I understand what you mean. Above you seemed to agree with
this. Maybe I should emphasise the "if it has to"? That is, when for
whatever reason, the client provided content is not directly suitable
for the output it will be displayed on.

> 
> > This is because an application will provide only one image for a
> > wl_surface, and the compositor may show that on any number of any kind
> > of outputs at once.  
> 
> That's a big problem. That assumes either that all displays are 
> interchangeable
> at the pixel level (they are not - they have different DPI and 
> Colorspaces/Gamut/HDR
> capability), or that Wayland has to know how to re-render to accommodate those
> difference (and Wayland doesn't do rendering, and may not want to include
> Colorspace conversion machinery or HDR colorspace/conversion machinery).

It will be the compositor that will automatically convert images to
whatever output they will be displayed on, just like the automatic
scaling with HiDPI. Wayland only needs to relay enough information that
the compositor can do that when necessary.

> > Nothing prevents adding more protocol to give apps more hints to behave
> > more optimally wrt. to the compositor's internal pipeline.  
> 
> There's a difference between hints that help speed and quality but
> still burden the compositor with doing display dependent conversions,
> and an approach that removes hat burden completely to the client when
> it does the rendering.

That burden cannot be eliminated in a general desktop environment.
There will always be situations where the compositor has to convert,
because a client has not or could not provide directly suitable content.

If we were to limit ourselves to narrow use cases outside of a generic
desktop system, then eliminating that burden might be possible. For
devices like TVs that would be highly desirable even. In the closed
system of a TV, all apps and all outputs are known beforehand, so the
operating system can simply avoid the general anything-to-anything
situations. Desktop systems are not that limited.

Weston needs to have all those correct conversions implemented. If
Weston gets used in an environment where those conversions are not
necessary, then Weston will simply not execute them.

> > Correct, and Shashank is not proposing anything different. The
> > per-channel lookup curves are a compositor internal detail, always
> > programmed by the compositor correctly according to what it happens to
> > be showing each monitor refresh on that specific monitor.  
> 
> Since the compositor is not Color Management aware, then by definition

The compositor must be made Color Management aware at some level.
Otherwise it will not expose any of the Wayland extensions that would
allow clients to submit content aside from the undefined(?) default
color space, or the extensions that would describe the output color
properties.

> it can't set the CRTC to the correct values ("correct" in terms
> of the color sensitive end users intentions for how they need their systems
> and applications to work.) Now if the compositor was CM aware, it could
> choose whether to implement CM display calibration curves by using
> the hardware CRTC, or by implementing it in some other fashion such
> as with a shader, or (ideally) by downloading the curve to the display
> itself (many high end displays have this capability, and the
> commercial CM tools do exactly that. How that could work with
> Wayland is another problem to ponder.)

Yes, a compositor must implement all that, but this is now slipping to
th

Re: HDR support in Wayland/Weston

[Graeme Gill]

Pekka Paalanen wrote:

Hi Pekka,
thanks for your response.

>> As far as I was informed, Wayland
>> is architected in such a way that this is not possible, since clients
>> have no knowledge of which display the pixels they send will end up on.
> 
> Nothing has changed there.

I've been pondering the various Color Management (CM) approaches to
working around this limitation, but I keep coming back to it
as the most fruitful direction to talk about. The main reasons
are that this implies the least extra burden on Wayland implementations,
and is most consonant with current application and GUI toolkit
CM code.

And in fact Wayland has already been changed in this direction already, to
accommodate a highly analogous requirement to that of Color Management :- HiDPI.
So as best I understand it, because (unlike X11) Wayland does not do
rendering, it is not reasonable for it to suddenly re-render application
graphics at hi resolution - the best that it can do is scale the pixels,
leading to poorer visual quality than is possible on HiDPI displays.
So HiDPI aware applications have to know when they are rendering for a HiDPI
output, and scale their buffers and rendering accordingly, and tell Wayland that
they have done so using wl_surface.set_buffer_scale. [ I am not currently
clear on how the situation of a user window straddling two displays of
differing DPI is handled. ]

The CM situation is highly analogous - like the DPI, the colorspace (profile)
of each output may be different for different displays, so for highest
quality output, something in the graphics chain needs to accommodate it.
To do so the relevant information is needed :- what output is being
rendered to, and what its characteristic is (DPI / Color Profile).

If done in the composer, it would need to render the graphic elements to
the output DPI / convert the source colorspace to the output colorspace.
But the composer would need the code to do rendering / convert colorspaces
(as well as being told what the graphic elements / source colorspace is),
and this is not the role Wayland has - that's the responsibility of the
client, so instead Wayland makes it possible for the client to know what DPI
it is rendering to. The analogous facility for CM is for the client to know
what output colorspace it is rendering for.

The clean/simplest approach to HDR is to treat it as just another output
colorspace, where it is up to the application to render the color
it intends to display, and the Wayland compositor is compositing everything
for that output in that HDR colorspace.

Now practically speaking this would assume that all Wayland clients connected
to an HDR display in HDR mode are CM/HDR aware, which is rather unlikely. So
some backward compatibility modes might be highly desirable (I have
some thoughts on that), but in any case, it would also help the quality
of such backward compatibility _and_ compositing (i.e. linear light
compositing option), if Wayland at least had access to the output color
profiles. So there is a lot of advantage in Wayland providing the
registry/API of output color profiles both for itself, and clients.

> Wayland and apps need to provide the compositor all the necessary
> information for the compositor to do all the conversions, mapping and
> blending correctly, if it has to.

And perhaps it shouldn't have to.

> This is because an application will provide only one image for a
> wl_surface, and the compositor may show that on any number of any kind
> of outputs at once.

That's a big problem. That assumes either that all displays are interchangeable
at the pixel level (they are not - they have different DPI and 
Colorspaces/Gamut/HDR
capability), or that Wayland has to know how to re-render to accommodate those
difference (and Wayland doesn't do rendering, and may not want to include
Colorspace conversion machinery or HDR colorspace/conversion machinery).

> Nothing prevents adding more protocol to give apps more hints to behave
> more optimally wrt. to the compositor's internal pipeline.

There's a difference between hints that help speed and quality but
still burden the compositor with doing display dependent conversions,
and an approach that removes hat burden completely to the client when
it does the rendering.

> Correct, and Shashank is not proposing anything different. The
> per-channel lookup curves are a compositor internal detail, always
> programmed by the compositor correctly according to what it happens to
> be showing each monitor refresh on that specific monitor.

Since the compositor is not Color Management aware, then by definition
it can't set the CRTC to the correct values ("correct" in terms
of the color sensitive end users intentions for how they need their systems
and applications to work.) Now if the compositor was CM aware, it could
choose whether to implement CM display calibration curves by using
the hardware CRTC, or by implementing it in some other fashion such
as with a shader, or (ideally) by

[PATCH wayland-web] xserver: new weston syntax

[Pekka Paalanen]

From: Pekka Paalanen 

The Xwayland setting syntax was changed in
https://gitlab.freedesktop.org/wayland/weston/commit/6d3887baec12c3a2b833301907546fba8c1fb26d

Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/186

Signed-off-by: Pekka Paalanen 
---
 xserver.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xserver.html b/xserver.html
index 0255d85..174b2ab 100644
--- a/xserver.html
+++ b/xserver.html
@@ -98,12 +98,12 @@ $ ln -s /usr/bin/xkbcomp $WLD/bin/
 weston.ini
 
 
-Add this to ~/.config/weston.ini (or use the 
--modules=xwayland.so command line argument):
+Add this to ~/.config/weston.ini (or use the --xwayland 
command line argument):
 
 
 
 [core]
-modules=xwayland.so
+xwayland=true
 
 
 Running
-- 
2.20.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

On Fri, 11 Jan 2019 18:25:01 +1100
Graeme Gill  wrote:

> Sharma, Shashank wrote:
> 
> Hi,
> 
> While I'm sure you could hard code various color space assumptions into
> such an implementation (and perhaps this is a pretty reasonable way
> of doing a proof of concept), it's not a good long term solution,
> and could end up being something of a millstone. What's missing
> is any serous Color Management in Wayland. It's a bigger project
> to fix that, but HDR would then be able to slot into a much more usable
> framework.

Hi,

that I agree with. At least the final design should aim to integrate
with color management related public application protocol extensions.

In other words, I think it would be ok to use place-holder extensions
if the color management extensions are not there yet, but plan for
swapping to the proper extension later when you aim for the larger
public.

In practise, that would mean more than one Wayland global interface for
HDR purposes, so that those that deal with color spaces can later be
dropped in favour of the color extensions instead of stabilized.

> > - HDR content/buffers are composed in REC2020 colorspace, with bit depth 
> > 10/12/16 BPC.
> > Some of the popular formats are P010,P012,P016.  
> 
> While REC2020 based HDR colorspaces are very popular, they aren't the only 
> ones out there.
> 
> > - Normal SRGB buffers are composed in SRGB color space following REC709 
> > specifications.  
> 
> As far as I'm aware (I haven't been closely monitoring this mailing
> list since the last rather long and unsatisfactory discussion about color
> management), Wayland works in display dependent colorspace, since there
> is no facility for it to know how to convert from anything else to the
> display space (i.e. no knowledge of display profiles so it doesn't
> know what sRGB is). In all other computer graphic display systems, it's
> up to the client to be informed about each display colorspace is, and
> to do color conversion to the display space either itself, or by using
> operating system libraries. The operating system provides the display
> profile information to allow this. As far as I was informed, Wayland
> is architected in such a way that this is not possible, since clients
> have no knowledge of which display the pixels they send will end up on.

Nothing has changed there.

> Also note that while the use of an intermediate compositing space is
> essential when combining different colorspace sources together, it's
> not desirable in other situations where maximum fidelity and
> gamut are desired i.e. Photography. (The double conversions are a
> possible accuracy loss, and it makes it very difficult to
> achieve good gamut mapping from large gamut sources.)

Right, ideally a series of conversions that should amount to identity
would be completely skipped on a frame by frame basis. Thankfully that
will be a compositor internal implementation detail - there should be
no protocol that demands unnecessary work.

> > - 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)  
> 
> Is that something that Wayland should really know about though ?
> i.e. shouldn't that be an application issue, where Wayland provides
> the necessary mechanisms to achieve correct composition ?
> (Or in fact is that what you are suggesting ?)

Wayland and apps need to provide the compositor all the necessary
information for the compositor to do all the conversions, mapping and
blending correctly, if it has to.

This is because an application will provide only one image for a
wl_surface, and the compositor may show that on any number of any kind
of outputs at once. The alternative would be for apps to provide one
image per each output for one wl_surface, so that the compositor can
pick the correctly rendered one - except that would still not allow the
compositor to blend correctly, it would only work for opaque windows.
It would also prohibit the use of display hardware to off-load any part
of the image processing.

But, just like HiDPI, it is not only the apps telling the compositor
what kind of image they are providing (wl_surface.set_buffer_scale
request). The compositor describes the outputs (wl_output.scale event)
so that applications can choose the best way to render, and maybe save
some work in the compositor at the same time.

Nothing prevents adding more protocol to give apps more hints to behave
more optimally wrt. to the compositor's internal pipeline.

> >     - Now, in order to re-apply the HDR curve, compositor will apply CRTC 
> > level gamma, so
> > that the output buffer is non-linear again.  
> 
> Note that in most Color Managed systems, the CRTC per channel lookup curves 
> are used for
> the purposes of display calibration, although Wayland doesn't currently 
> support
> Color 

Re: HDR support in Wayland/Weston

[Pekka Paalanen]

On Thu, 10 Jan 2019 20:32:18 +0530
"Sharma, Shashank"  wrote:

> 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 same can be found here: 
> https://patchwork.freedesktop.org/series/25091/
>  - And they will ever live happily after :).
> 
> Please provide inputs, feedbacks and suggestions for this design and 
> plan, so that we can improve out half cooked solution, and start sending 
> the patches.

Hi Shashank,

this is a major feature that would be awesome to have in Weston, but
it's also a big effort to design, implement, and maintain. To ease the
maintenance, we will need some serious work on the test suite, which
currently cannot even run the GL-renderer.

I understand your aim is to leverage display hardware capabilities to
the fullest, but we must also consider hardware that lacks some or all
of the conversion/mapping/other features while the monitor is well
HDR-capable. We also need to consider what happens when a monitor is
not HDR-capable or is somehow lacking. OTOH, whether a compositor
implements HDR support at all would be obvious in the advertised
Wayland globals and pixel formats.

Do we want to support HDR output in some way even if the disp

[PATCH wayland-web 8/9] building: switch weston to meson

[Pekka Paalanen]

From: Pekka Paalanen 

Use Meson in the guide, autotools is on its way out.

Signed-off-by: Pekka Paalanen 
---
 building.html | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/building.html b/building.html
index 4f28f9e..61376d7 100644
--- a/building.html
+++ b/building.html
@@ -179,20 +179,37 @@ libinput docs for instructions on how to build it.
 available in the weston repo and comes with a few demo applications.
 
 
+Weston is built with https://mesonbuild.com/";>Meson. The last
+Weston release with autotools build system is probably the February/March 2019
+release. If necessary, the latest Meson can be installed as a user with:
+
+$ pip3 install --user meson
+
+
+Weston's Meson build does not do autodetection and it defaults to all
+features enabled, which means you likely hit missing dependencies on the first
+try. If a dependency is avoidable through a build option, the error message
+should tell you what option can be used to avoid it. You may need to disable
+several features if you want to avoid certain dependencies.
+
 
 $ git clone https://gitlab.freedesktop.org/wayland/weston.git";>https://gitlab.freedesktop.org/wayland/weston.git
 $ cd weston
-$ ./autogen.sh --prefix=$WLD
-$ make
-$ sudo make install
+$ meson build/ --prefix=$WLD
+$ ninja -C build/ install
 $ cd ..
 
 
-
-Use --disable-setuid-install to avoid having to
-use sudo make install. This is useful
-if you only plan to run weston under X.
-
+The meson command populates the build directory. This step can
+fail due to missing dependencies. Any build options you want can be added on
+that line, e.g. meson build/ --prefix=$WLD 
-Dsimple-dmabuf-drm=intel.
+All the build options can be found in the file
+https://gitlab.freedesktop.org/wayland/weston/blob/master/meson_options.txt";>meson_options.txt.
+
+Once the build directory has been successfully populated, you can inspect 
the
+configuration with meson configure build/. If you need to change 
an
+option, you can do e.g.
+meson configure build/ -Dsimple-dmabuf-drm=intel.
 
 Running Weston
 
-- 
2.20.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-web 9/9] index: weston has own contribution instructions

[Pekka Paalanen]

From: Pekka Paalanen 

The Wayland and Weston instructions are different.

Signed-off-by: Pekka Paalanen 
---
 index.html | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/index.html b/index.html
index ab6259f..320cd9a 100644
--- a/index.html
+++ b/index.html
@@ -54,7 +54,8 @@ embedded and mobile use cases.  
   http://patchwork.freedesktop.org/project/wayland/list/";>Patchwork: 
pending Wayland and Weston patches
   Reviewing Patches (please help)
   Testing Wayland
-  https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md";>Contribution
 instructions
+  https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md";>Contribution
 instructions for Wayland
+  https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md";>Contribution
 instructions for Weston
   https://gitlab.freedesktop.org/wayland/wayland/issues";>Wayland 
bugs
   https://gitlab.freedesktop.org/wayland/weston/issues";>Weston 
bugs
 
-- 
2.20.1

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Graeme Gill]

Sharma, Shashank wrote:

Hi,

While I'm sure you could hard code various color space assumptions into
such an implementation (and perhaps this is a pretty reasonable way
of doing a proof of concept), it's not a good long term solution,
and could end up being something of a millstone. What's missing
is any serous Color Management in Wayland. It's a bigger project
to fix that, but HDR would then be able to slot into a much more usable
framework.

> - HDR content/buffers are composed in REC2020 colorspace, with bit depth 
> 10/12/16 BPC.
> Some of the popular formats are P010,P012,P016.

While REC2020 based HDR colorspaces are very popular, they aren't the only ones 
out there.

> - Normal SRGB buffers are composed in SRGB color space following REC709 
> specifications.

As far as I'm aware (I haven't been closely monitoring this mailing
list since the last rather long and unsatisfactory discussion about color
management), Wayland works in display dependent colorspace, since there
is no facility for it to know how to convert from anything else to the
display space (i.e. no knowledge of display profiles so it doesn't
know what sRGB is). In all other computer graphic display systems, it's
up to the client to be informed about each display colorspace is, and
to do color conversion to the display space either itself, or by using
operating system libraries. The operating system provides the display
profile information to allow this. As far as I was informed, Wayland
is architected in such a way that this is not possible, since clients
have no knowledge of which display the pixels they send will end up on.

Also note that while the use of an intermediate compositing space is
essential when combining different colorspace sources together, it's
not desirable in other situations where maximum fidelity and
gamut are desired i.e. Photography. (The double conversions are a
possible accuracy loss, and it makes it very difficult to
achieve good gamut mapping from large gamut sources.)

> - 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)

Is that something that Wayland should really know about though ?
i.e. shouldn't that be an application issue, where Wayland provides
the necessary mechanisms to achieve correct composition ?
(Or in fact is that what you are suggesting ?)

>     - Now, in order to re-apply the HDR curve, compositor will apply CRTC 
> level gamma, so
> that the output buffer is non-linear again.

Note that in most Color Managed systems, the CRTC per channel lookup curves are 
used for
the purposes of display calibration, although Wayland doesn't currently support
Color Management tools at all (unlike X11 or other operating systems, it 
provides no
access to the CRTC by client software).

Perhaps it's worth re-visiting some of the ideas about how to add Color 
Management
to Wayland, to see how HDR could fit into it ?

regards,
Graeme Gill
(Author of ArgyllCMS )
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: HDR support in Wayland/Weston

[Sharma, Shashank]

Hello Ole,


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
Thanks for sharing the links, let me go through the discussion history, 
I will come back with my feedback for this stack, soon.

- Shashank

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 same can be found here:
https://patchwork.freedesktop.org/series/25091/
  - And they will ever live happily after :).

Please provide inputs, feedbacks and suggestions for this design and
plan, so that we can improve out half cooked solution, and start sending
the patches.

   +--+ +---+

   | SDR Buffer subtitles   | HDR

Re: HDR support in Wayland/Weston

[Niels Ole Salscheider]

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 same can be found here:
> https://patchwork.freedesktop.org/series/25091/
>  - And they will ever live happily after :).
> 
> Please provide inputs, feedbacks and suggestions for this design and
> plan, so that we can improve out half cooked solution, and start sending
> the 

Re: HDR support in Wayland/Weston

[Sharma, Shashank]

If the block diagram is not aligned due to mail client, please refer to 
the attached .txt file. Hope thats slightly better :).


Regards

Shashank

On 1/10/2019 8:32 PM, Sharma, Shashank wrote:

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 same can be found here: 
https://patchwork.freedesktop.org/series/25091/

- And they will ever live happily after :).

Please provide inputs, feedbacks and suggestions for this design and 
plan, so that we can improve out half cooked solution, and start 
sending the patches.


 +--+ +---+
 | SDR Buffer subtitles   | HDR Buffer video
 | (REC  709 colorsp) | (REC 2020 colorsp |
 |  | |   |
 +---+--+ +---+---+
 ||
 ||
 ||
+--v---v+ +--+
  |   Compositor: v   | | 
LibVA|
  |   - assigns views to overlays 
+-> Tone mapping |
  |   - prepare plane/CRTC color properties   
<-+ SDR to HDR   |
  | for linear blending in display
|  

HDR support in Wayland/Weston

[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 same can be found here: 
https://patchwork.freedesktop.org/series/25091/

- And they will ever live happily after :).

Please provide inputs, feedbacks and suggestions for this design and 
plan, so that we can improve out half cooked solution, and start sending 
the patches.


 +--+ +---+
 | SDR Buffer subtitles   | HDR Buffer video
 | (REC  709 colorsp) | (REC 2020 colorsp |
 |  | |   |
 +---+--+ +---+---+
 ||
 ||
 ||
+--v---v+ +--+
  |   Compositor: v   | | 
LibVA|
  |   - assigns views to overlays 
+-> Tone mapping |
  |   - prepare plane/CRTC color properties   
<-+ SDR to HDR   |
  | for linear blending in display
| | HDR to SDR   |

+--+-+--+ +--+
 | |
 | Tone mapped | Tone mapped
 | non-linear-Rec709   | 

Re: Weston headless backend - xvfb-run emulation

[Martin Stransky]

On 12/22/18 10:36 AM, Pekka Paalanen wrote:

On Fri, 21 Dec 2018 13:00:12 +0100
Martin Stransky  wrote:


Hi,

I'm working on Firefox/Wayland port on Fedora and there's a need to run
Wayland Firefox in headless Wayland session - it's used in build process
to perform PGO build, it's used for test runs and so. It's generally
what xvfb-run provides - a headless X11 server which launches a single
command and quit when the command finishes.

Is that possible with Weston and any of its backend? I haven't found any
reference how to launch firefox inside weston-headles backend
automatically so far.


Hi,

Weston doesn't have any kind of autolaunch feature, but there are
interested people at least for the desktop use case.

Weston's own test suite uses a custom plugin to launch test
clients, but it's not installed. That might be a better approach
for a test suite than a generic desktop app autolaunch, since you
can make the compositor quit and forward the test app exit code.

That plugin is at tests/weston-test.c, and it implements also a
test protocol, but the most relevant part for you is
idle_launch_client(). test_client_sigchld() handles quitting Weston.

We could think of some kind of arrangement to allow using
Weston/headless to run automated tests in other projects
out-of-the-box. Maybe the idle_launch_client() functionality could
be integrated in the headless backend directly... but then we need
more changes in Weston's test suite to allow running the tests with
different backends. Maybe that would be a slightly longer term plan.

Are you only looking for headless launching of apps, or would you
be interested in more features like screenshooting or fake input
events to drive and check tests?


Hello,

Mozilla uses xvfb as a frame buffer X server and launches x11vnc inside 
it. The Firefox itself is controlled by Marionette [1] so there's no 
need for fake input events (AFAIK). Also the screen capture is not 
necessary for now.


A good start would be to launch Firefox inside wayland headless session 
and I can work from this point further to investigate what's needed. If 
the plugin provides such functionality that will be fine for now.


Thanks,
ma.

[1] 
https://firefox-source-docs.mozilla.org/testing/marionette/marionette/index.html


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCEMENT] Weston builds with Meson, grace period for autotools

[Pekka Paalanen]

On Fri, 14 Dec 2018 19:22:27 +0200
Pekka Paalanen  wrote:

> On Fri, 14 Dec 2018 15:16:29 +0100 (CET)
> Jan Engelhardt  wrote:
> 
> > [3s] + /usr/bin/meson --buildtype=plain --prefix=/usr 
> > --libdir=/usr/lib64
> > --libexecdir=/usr/lib --bindir=/usr/bin --sbindir=/usr/sbin
> > --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man
> > --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc
> > --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload
> > --auto-features=enabled . build -Ddemo-clients=false -Dremoting=false
> > -Dsimple-clients=
> > 
> > It still wants pangocairo -- and that's the point where I'd get frustrated.
> > (because shared/, unlike clients/, seems to have it marked as optional 
> > already AFAICT)  
> 
> Hi Jan,
> 
> this hopefully fixes the issue with pangocairo and demonstrates
> what kind of error messages I envision to have for roughly
> everything:
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/72
> 
> Could you give it a try?

Hi Jan,

FYI, this was just merged to master.

Another MR
https://gitlab.freedesktop.org/wayland/weston/merge_requests/75 aims to
improve more of the "not found" cases, but even that still leaves the
tests/ subdirectory untouched, which means dependencies like Cairo and
EGL cannot be fully disabled yet, IIRC.


Thanks,
pq


pgpJeCYCAsLVE.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston headless backend - xvfb-run emulation

[Pekka Paalanen]

On Fri, 21 Dec 2018 13:00:12 +0100
Martin Stransky  wrote:

> Hi,
> 
> I'm working on Firefox/Wayland port on Fedora and there's a need to run 
> Wayland Firefox in headless Wayland session - it's used in build process 
> to perform PGO build, it's used for test runs and so. It's generally 
> what xvfb-run provides - a headless X11 server which launches a single 
> command and quit when the command finishes.
> 
> Is that possible with Weston and any of its backend? I haven't found any 
> reference how to launch firefox inside weston-headles backend 
> automatically so far.

Hi,

Weston doesn't have any kind of autolaunch feature, but there are
interested people at least for the desktop use case.

Weston's own test suite uses a custom plugin to launch test
clients, but it's not installed. That might be a better approach
for a test suite than a generic desktop app autolaunch, since you
can make the compositor quit and forward the test app exit code.

That plugin is at tests/weston-test.c, and it implements also a
test protocol, but the most relevant part for you is
idle_launch_client(). test_client_sigchld() handles quitting Weston.

We could think of some kind of arrangement to allow using
Weston/headless to run automated tests in other projects
out-of-the-box. Maybe the idle_launch_client() functionality could
be integrated in the headless backend directly... but then we need
more changes in Weston's test suite to allow running the tests with
different backends. Maybe that would be a slightly longer term plan.

Are you only looking for headless launching of apps, or would you
be interested in more features like screenshooting or fake input
events to drive and check tests?


Thanks,
pq


pgpsfJegW1lgA.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Weston headless backend - xvfb-run emulation

[Martin Stransky]

Hi,

I'm working on Firefox/Wayland port on Fedora and there's a need to run 
Wayland Firefox in headless Wayland session - it's used in build process 
to perform PGO build, it's used for test runs and so. It's generally 
what xvfb-run provides - a headless X11 server which launches a single 
command and quit when the command finishes.


Is that possible with Weston and any of its backend? I haven't found any 
reference how to launch firefox inside weston-headles backend 
automatically so far.


Thanks,
ma.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCEMENT] Weston builds with Meson, grace period for autotools

[Pekka Paalanen]

On Fri, 14 Dec 2018 15:16:29 +0100 (CET)
Jan Engelhardt  wrote:

> [3s] + /usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64
> --libexecdir=/usr/lib --bindir=/usr/bin --sbindir=/usr/sbin
> --includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man
> --infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc
> --localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload
> --auto-features=enabled . build -Ddemo-clients=false -Dremoting=false
> -Dsimple-clients=
> 
> It still wants pangocairo -- and that's the point where I'd get frustrated.
> (because shared/, unlike clients/, seems to have it marked as optional 
> already AFAICT)

Hi Jan,

this hopefully fixes the issue with pangocairo and demonstrates
what kind of error messages I envision to have for roughly
everything:
https://gitlab.freedesktop.org/wayland/weston/merge_requests/72

Could you give it a try?


Thanks,
pq


pgp6npPLtMC9p.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCEMENT] Weston builds with Meson, grace period for autotools

[Pekka Paalanen]

On Fri, 14 Dec 2018 15:16:29 +0100 (CET)
Jan Engelhardt  wrote:

> On Wednesday 2018-12-12 18:16, Pekka Paalanen wrote:
> >
> >here is an early Christmas / NewYear present / bomb (take your pick). I just
> >merged https://gitlab.freedesktop.org/wayland/weston/merge_requests/8 which
> >adds Meson build system to Weston.
> >
> >Most build options are equivalent to their autoconf counterparts, but some
> >have been redesigned, hopefully in a more obvious way.
> >
> >Most options do not have an auto setting, and everything defaults
> >to enabled [...]  
> 
> Not convinced I like that.
> 
> [5s] Dependency pangocairo found: NO (tried pkgconfig)
> [5s] clients/meson.build:205:0: ERROR:  Dependency "pangocairo" not 
> found, tried pkgconfig
> 
> Ok, so let's see, what option do I need to disable pangocairo... of course 
> it's
> not documented, so all that's left is a grep. Easy enough.

> weston/clients/meson.build: 'add_deps': [ 
> dependency('pangocairo') ]

You have found a bug! :-)

-Ddemo-clients=false should get rid of this, but doesn't. I'll keep
that in mind to fix.


Thanks,
pq


pgpzdntfNJnzO.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCEMENT] Weston builds with Meson, grace period for autotools

[Jan Engelhardt]

On Wednesday 2018-12-12 18:16, Pekka Paalanen wrote:
>
>here is an early Christmas / NewYear present / bomb (take your pick). I just
>merged https://gitlab.freedesktop.org/wayland/weston/merge_requests/8 which
>adds Meson build system to Weston.
>
>Most build options are equivalent to their autoconf counterparts, but some
>have been redesigned, hopefully in a more obvious way.
>
>Most options do not have an auto setting, and everything defaults
>to enabled [...]

Not convinced I like that.

[5s] Dependency pangocairo found: NO (tried pkgconfig)
[5s] clients/meson.build:205:0: ERROR:  Dependency "pangocairo" not found, 
tried pkgconfig

Ok, so let's see, what option do I need to disable pangocairo... of course it's
not documented, so all that's left is a grep. Easy enough.

15:11 a4:../Wayland/weston > grep -r pangocairo
weston/clients/editor.c:#include 
weston/clients/meson.build:     'add_deps': [ dependency('pangocairo') ]
weston/shared/meson.build:dep_pangocairo = dependency('pangocairo', required: 
false)
weston/shared/meson.build:if dep_pango.found() and dep_pangocairo.found() and 
dep_glib.found()
weston/shared/meson.build:  deps_cairo_shared += [ dep_pango, 
dep_pangocairo, dep_glib ]

[3s] + /usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64
--libexecdir=/usr/lib --bindir=/usr/bin --sbindir=/usr/sbin
--includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man
--infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc
--localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload
--auto-features=enabled . build -Ddemo-clients=false -Dremoting=false
-Dsimple-clients=

It still wants pangocairo -- and that's the point where I'd get frustrated.
(because shared/, unlike clients/, seems to have it marked as optional already 
AFAICT)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCEMENT] Weston builds with Meson, grace period for autotools

[Pekka Paalanen]

Hi,

here is an early Christmas / NewYear present / bomb (take your
pick). I just merged
https://gitlab.freedesktop.org/wayland/weston/merge_requests/8
which adds Meson build system to Weston.

The Meson build may not be too polished everywhere, but it should
be fully functional and correct. Most build options are equivalent
to their autoconf counterparts, but some have been redesigned,
hopefully in a more obvious way.

Most options do not have an auto setting, and everything defaults
to enabled, so quite probably you need to do little adjustments to
get it to build. Instead of auto, I thought it would better to make
the build configuration explicit, and help people choose the right
disables through informative error messages that explain what
option to use if they really do not want to build the feature.
Making all dependency errors user-friendly is a work in progress
though.

If you feel strongly about needing auto options, we can see about
adding those.

Now we have two build systems in Weston: autotools and meson. This
means that all work landing upstream, that touches something about
the build, will need to patch both build systems equally, until
autotools is removed.

The autotools build will remain as fully supported in the coming
Weston release some time in January - March. However, right after
the final release on that cycle, I would like to remove autotools.
Therefore we will have one and only one Weston release (not
counting release candidates etc.) that has both build systems.
Hopefully this gives enough time for distributions to transition.

Would be nice to start testing the Meson build and iron out any
wrinkles it may have before the next release.

http://mesonbuild.com


Thanks,
pq


pgp4y6RjdPCRS.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston: output scaling does not seem to have any effect

[Peter Bašista]

On Mon, Dec 10, 2018 at 10:57:17AM +0200, Pekka Paalanen wrote:
> What error messages did you get? Or do you meant that you didn't get
> any?
I need to correct myself. I did not get any messages related to scaling
not being applied from the ordinary runs (i.e. without extra arguments)
of either of the following commands:

1. weston
2. weston --debug
3. weston-launch
4. weston-launch -v

When I tried to run "weston --scale=2", the following error message
appeared:

fatal: unhandled option: --scale=2

which prompted me to investigate further. I have tried to specify the
correct output name mostly because it appeared in the same log.
I did not consider it important for scaling to work,
so I probably would not try to find its correct value manually.

> I don't think printing messages about unused sections in weston.ini
> would be good, because different backends use different sections and
> have different named outputs. But, Weston could be more verbose about
> what it actually uses from weston.ini.

I agree. There could be a message saying which sections
are looked up during the startup. Then there could be a message
saying which settings are actually in use for each section,
taking defaults and command line argument overrides into account.

For example:

looking up configuration section for output DP-1: not found

DP-1 output settings:
scale=1
...

I think that this may be a "solved problem" already
and that there may be approaches which take care of logging
in a way that helps the user to diagnose and debug issues.

Regards
Peter Bašista
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston: output scaling does not seem to have any effect

[Pekka Paalanen]

On Sun, 9 Dec 2018 16:07:22 +0100
Peter Bašista  wrote:

> Hi,
> 
> Weston does not seem to perform any output scaling unless an explicit and
> correct output name is given.

Hi,

yes, that is correct. A correct output name must be given.

> At least in my case, it was *not* sufficient
> to add the following section to weston.ini:
> 
> [output]
> scale=2
> 
> With such a configuration, weston-launch would launch Weston normally, but
> there would be no scaling. The manual page does not explain what could be
> causing such a behavior.
> 
> It only started to work for me when I manually looked up the correct name
> for my output from the output of "weston --debug" and added it to the
> configuration section:
> 
> [output]
> name=DP-1
> scale=2
> 
> I do not understand the details of how it is supposed to work properly. The
> current error messages (wayland 1.16.0, weston 5.0.90) were not very
> helpful to me. A better explanation should, in my opinion, be added to the
> man page.

You are right. The manual for output section is out-dated and even
somewhat self-contradicting.

What error messages did you get? Or do you meant that you didn't get
any?

I don't think printing messages about unused sections in weston.ini
would be good, because different backends use different sections and
have different named outputs. But, Weston could be more verbose about
what it actually uses from weston.ini.

A weston.ini can have multiple output sections, and which one applies
to which output is determined by the name key.


Thanks,
pq


pgp5zEv90PZsQ.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Weston: output scaling does not seem to have any effect

[Peter Bašista]

Hi,

Weston does not seem to perform any output scaling unless an explicit and
correct output name is given. At least in my case, it was *not* sufficient
to add the following section to weston.ini:

[output]
scale=2

With such a configuration, weston-launch would launch Weston normally, but
there would be no scaling. The manual page does not explain what could be
causing such a behavior.

It only started to work for me when I manually looked up the correct name
for my output from the output of "weston --debug" and added it to the
configuration section:

[output]
name=DP-1
scale=2

I do not understand the details of how it is supposed to work properly. The
current error messages (wayland 1.16.0, weston 5.0.90) were not very
helpful to me. A better explanation should, in my opinion, be added to the
man page.

Regards
Peter Bašista
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston making system slow

[Pekka Paalanen]

On Fri, 30 Nov 2018 09:41:54 +0530
deepan muthusamy  wrote:

> I have Weston without notify enabled, with this Weston my UI application
> performance is fast.
> 
> But I changed to Weston with notify, because I have to start as system
> service. I followed the procedure provided by you guys only.
> Now my UI application performance has reduced means application gets
> slow.responding very slow.
> Is Weston with notify lead to any performance degradation?

No, it should not have any effect.

I cannot imagine how using the systemd-notify plugin could ever affect
Weston's runtime performance after start-up. You need to profile and
debug it yourself.


Thanks,
pq


pgp__amVbPoW8.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Weston making system slow

[deepan muthusamy]

I have Weston without notify enabled, with this Weston my UI application
performance is fast.

But I changed to Weston with notify, because I have to start as system
service. I followed the procedure provided by you guys only.
Now my UI application performance has reduced means application gets
slow.responding very slow.
Is Weston with notify lead to any performance degradation?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [systemd-devel] Not able to start Weston dependent application

[Jérémy Rosen]

Did you add an "After=" too ? you need both  a Requires= and an After=
Did you activate any security feature that might hide the wayland socket 
from app2 ?


On 31/10/2018 08:21, deepan muthusamy wrote:

Hi,
I started app1(this is a UI application) as system service .
I started app2( this is Weston ) also as system service. But in 
different tty(tty7).


App1 is depended on app2 to start.
I added that dependency.

App2 is started but app1 not able to find that dependency. Iam getting 
error as not able to find weston.


If I start both manually, it's working fine.




___
systemd-devel mailing list
systemd-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
SMILE <http://www.smile.eu/>

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr <mailto:jeremy.ro...@smile.fr>
phone +33141402967
url http://www.smile.eu

Twitter <https://twitter.com/GroupeSmile> Facebook 
<https://www.facebook.com/smileopensource> LinkedIn 
<https://www.linkedin.com/company/smile> Github 
<https://github.com/Smile-SA>



Découvrez l’univers Smile, rendez-vous sur smile.eu 
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>


eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [systemd-devel] Not able to start Weston dependent application

[Lennart Poettering]

On Mi, 31.10.18 12:51, deepan muthusamy (deepan.m2...@gmail.com) wrote:

> Hi,
> I started app1(this is a UI application) as system service .
> I started app2( this is Weston ) also as system service. But in different
> tty(tty7).
> 
> App1 is depended on app2 to start.
> I added that dependency.
> 
> App2 is started but app1 not able to find that dependency. Iam getting
> error as not able to find weston.
> 
> If I start both manually, it's working fine.

Does app2 have the right Type= set so that systemd actually knows when
the service is properly started up? 

Lennart

-- 
Lennart Poettering, Red Hat
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Not able to start Weston dependent application

[deepan muthusamy]

Hi,
I started app1(this is a UI application) as system service .
I started app2( this is Weston ) also as system service. But in different
tty(tty7).

App1 is depended on app2 to start.
I added that dependency.

App2 is started but app1 not able to find that dependency. Iam getting
error as not able to find weston.

If I start both manually, it's working fine.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: error weston-launch from virtual terminal

[Pekka Paalanen]

On Mon, 15 Oct 2018 13:02:41 +0530
Iqbal Inzamam  wrote:

> I'm using Ubuntu 18.04. when i try weston-launch from virtual terminal with
> no weston config file i get an error saying.
> "failed to create input device option 'seat', udev device property ID_SEAT"
> just running weston in normal terminal (within x11) works fine
> 
> please help me to run weston-launch.

Hi,

Ubuntu 18.04 is using systemd-logind. Why do want to use weston-launch
despite of that? Simply 'weston' should work on the virtual terminal as
well.

Your error message is garbled too. Please, redirect both stdout and
stderr to a file and inspect the file contents. Printing to the virtual
terminal stops working correctly as soon as Weston switches the TTY to
graphics mode.


Thanks,
pq


pgpyAbrXkPxdK.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

error weston-launch from virtual terminal

[Iqbal Inzamam]

I'm using Ubuntu 18.04. when i try weston-launch from virtual terminal with
no weston config file i get an error saying.
"failed to create input device option 'seat', udev device property ID_SEAT"
just running weston in normal terminal (within x11) works fine

please help me to run weston-launch.

Thanks.
M.I Inzamam
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Launch Weston at tty1

[Singh, Satyeshwar]

Yes, not sure what was the issue around TTYs.

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Pekka Paalanen
Sent: Thursday, September 27, 2018 12:41 AM
To: Singh, Satyeshwar 
Cc: Jan Engelhardt ; deepan muthusamy 
; wayland-devel@lists.freedesktop.org
Subject: Re: Launch Weston at tty1

On Wed, 26 Sep 2018 17:59:37 +
"Singh, Satyeshwar"  wrote:

> Saw a response from Deepan where he said "I changed type from notify 
> to simple. Now problem has been solved. Thank you".
> 

Right. That cannot possibly make any difference between TTYs though.


Thanks,
pq

> 
> -Original Message-
> From: wayland-devel 
> [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Jan 
> Engelhardt
> Sent: Wednesday, September 26, 2018 12:16 AM
> To: deepan muthusamy 
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: Launch Weston at tty1
> 
> On Wednesday 2018-09-26 06:08, deepan muthusamy wrote:
> 
> >I can able to launch Weston at tty7 but not able to launch at tty1. Why??  
> 
> Probably because the tty is already allocated. (man deallocvt) 
> ___
> 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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Launch Weston at tty1

[Pekka Paalanen]

On Wed, 26 Sep 2018 17:59:37 +
"Singh, Satyeshwar"  wrote:

> Saw a response from Deepan where he said "I changed type from notify
> to simple. Now problem has been solved. Thank you".
> 

Right. That cannot possibly make any difference between TTYs though.


Thanks,
pq

> 
> -Original Message-
> From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
> Behalf Of Jan Engelhardt
> Sent: Wednesday, September 26, 2018 12:16 AM
> To: deepan muthusamy 
> Cc: wayland-devel@lists.freedesktop.org
> Subject: Re: Launch Weston at tty1
> 
> On Wednesday 2018-09-26 06:08, deepan muthusamy wrote:
> 
> >I can able to launch Weston at tty7 but not able to launch at tty1. Why??  
> 
> Probably because the tty is already allocated. (man deallocvt) 
> ___
> 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



pgpbmUa4b1yiD.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Launch Weston at tty1

[Singh, Satyeshwar]

Saw a response from Deepan where he said "I changed type from notify to simple. 
Now problem has been solved. Thank you".


-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Jan Engelhardt
Sent: Wednesday, September 26, 2018 12:16 AM
To: deepan muthusamy 
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: Launch Weston at tty1

On Wednesday 2018-09-26 06:08, deepan muthusamy wrote:

>I can able to launch Weston at tty7 but not able to launch at tty1. Why??

Probably because the tty is already allocated. (man deallocvt) 
___
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: Launch Weston at tty1

[Jan Engelhardt]

On Wednesday 2018-09-26 06:08, deepan muthusamy wrote:

>I can able to launch Weston at tty7 but not able to launch at tty1. Why??

Probably because the tty is already allocated. (man deallocvt)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Launch Weston at tty1

[Daniel Stone]

Hi Deepan,

On Wed, 26 Sep 2018 at 06:08, deepan muthusamy  wrote:
> I can able to launch Weston at tty7 but not able to launch at tty1. Why??

Again, no idea without any further information. As with your last
mail, please attach logs, exact steps and results, and enough
information to help us help you. You may also be better using GitLab
to file issues rather than the mailing list.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Launch Weston at tty1

[deepan muthusamy]

I can able to launch Weston at tty7 but not able to launch at tty1. Why??
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re:Re: did the weston can use "mesa" for "opengles and egl" demands without libmali.so on MALI targets?

[tugouxp]

is that mean that the libmali.so could be replaced by mesa implementation 
totally? if so, the accelerator function could not be used, is that true?


i would make experiment as you said, thanks for our good advice.








At 2018-09-25 16:52:21, "Pekka Paalanen"  wrote:
>On Tue, 25 Sep 2018 09:28:27 +0800 (CST)
>tugouxp <13824125...@163.com> wrote:
>
>> hi folks:
>> 
>> 
>> my project take wayland as display server, weston working with
>> libdrm-backend, the opegles and egl interface are provided by arm
>> official provide "libmali.so" library.
>> 
>> 
>> but now i want to test whether it can be worked that get rid of  mali
>> library completely ,and use mesa library instead.  i am use the yocto
>> build system and the compile process is very succefully, but when i
>> tested the weston with  following command.
>> 
>> weston --backend=drm-backend.so --tty=1 --idle-time=0 &
>> 
>> it seems the weston crashed and cant  be launched,  this command
>> works fine with "libmali" method, so it should not be the problem of
>> mali .
>> 
>> 
>> the output is very chaos by different threads log interrupted each
>> other, thanks for your kindly help.
>> 
>
>Hi,
>
>you can redirect stdout and stderr to a file. Printing to the terminal
>stops working once Weston enters graphics mode. If you are launching
>weston through a serial console, maybe it overflows and drops random
>bytes - is your serial flow control correctly set up also for the
>kernel console output?
>
>It looks like you get kernel bug output too. A kernel bug is always a
>kernel issue, so you would need to look into that first.
>
>Also make sure that Weston is not somehow patched for Mali
>specifically. I don't know if such patches exist, but if they do, we
>can't support them.
>
>This page seems to summarize the status of FOSS drivers:
>https://wiki.debian.org/MaliGraphics
>
>See also the upcoming XDC presentation about Panfrost this week:
>https://www.x.org/wiki/Events/XDC2018/Talks/#lyude_alyssa
>
>
>Thanks,
>pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: did the weston can use "mesa" for "opengles and egl" demands without libmali.so on MALI targets?

[Pekka Paalanen]

On Tue, 25 Sep 2018 09:28:27 +0800 (CST)
tugouxp <13824125...@163.com> wrote:

> hi folks:
> 
> 
> my project take wayland as display server, weston working with
> libdrm-backend, the opegles and egl interface are provided by arm
> official provide "libmali.so" library.
> 
> 
> but now i want to test whether it can be worked that get rid of  mali
> library completely ,and use mesa library instead.  i am use the yocto
> build system and the compile process is very succefully, but when i
> tested the weston with  following command.
> 
> weston --backend=drm-backend.so --tty=1 --idle-time=0 &
> 
> it seems the weston crashed and cant  be launched,  this command
> works fine with "libmali" method, so it should not be the problem of
> mali .
> 
> 
> the output is very chaos by different threads log interrupted each
> other, thanks for your kindly help.
> 

Hi,

you can redirect stdout and stderr to a file. Printing to the terminal
stops working once Weston enters graphics mode. If you are launching
weston through a serial console, maybe it overflows and drops random
bytes - is your serial flow control correctly set up also for the
kernel console output?

It looks like you get kernel bug output too. A kernel bug is always a
kernel issue, so you would need to look into that first.

Also make sure that Weston is not somehow patched for Mali
specifically. I don't know if such patches exist, but if they do, we
can't support them.

This page seems to summarize the status of FOSS drivers:
https://wiki.debian.org/MaliGraphics

See also the upcoming XDC presentation about Panfrost this week:
https://www.x.org/wiki/Events/XDC2018/Talks/#lyude_alyssa


Thanks,
pq


pgpEcHNkhZkDQ.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

did the weston can use "mesa" for "opengles and egl" demands without libmali.so on MALI targets?

[tugouxp]

hi folks:


my project take wayland as display server, weston working with 
libdrm-backend, the opegles and egl interface are provided by arm official 
provide "libmali.so" library.


but now i want to test whether it can be worked that get rid of  mali library 
completely ,and use mesa library instead.  i am use the yocto build system and 
the compile process is very succefully, but
when i tested the weston with  following command.

weston --backend=drm-backend.so --tty=1 --idle-time=0 &

it seems the weston crashed and cant  be launched,  this command works fine 
with "libmali" method, so it should not be the problem of mali .


the output is very chaos by different threads log interrupted each other, 
thanks for your kindly help.


[12:24:33.474] OS: Linux, 4.4.[   21.028359] weston[1248]: unhandled level 2 
translation fault (11) at 0x0008, esr 0x9246
89, #14 SMP PREEMPT Sat Sep 22 2[   21.040046] pgd = ffc029da9000
2:05:37 CST 2018, aarch64
[12:2[   21.046565] [0008] *pgd=68e4f0034:33.474] Using config file 
'/et, *pud=68e4f003c/xdg/weston/weston.ini'
[12:24, *pmd=:33.475] Output repaint window i
s 7 ms maximum.
[12:24:33.475] [   21.066890] 
Loading module '/usr/lib/libwest[   21.071338] CPU: 0 PID: 1248 Comm: weston 
Tainted: G   O4.4.89 #14
on-2/drm-backend.so'
[12:24:33.[   21.082139] Hardware name: sun50iw1 (DT)
477] initializing drm backend
[[   21.089289] task: ffc02a0dd080 ti: ffc02a35c000 task.ti: 
ffc02a35c000
12:24:33.482] using /dev/dri/car[   21.100373] PC is at 0x7fa0b745cc
d0
[12:24:33.482] Loading modul[   21.106838] LR is at 0x7fa06ca3ac
e '/usr/lib/libweston-2/gl-rende[   21.113294] pc : [<007fa0b745cc>] lr : 
[<007fa06ca3ac>] pstate: 8000
rer.so'
gbm: failed to open any[   21.124302] sp : 007fe00b72d0
 driver (search paths /usr/lib/d[   21.130758] x29: 007fe00b72d0 ri)
gbm: Last dlopen error: /usx28: 0040a000 r/lib/dri/sunxi_dri.so: cannot 
o
pen shared object file: No such [   21.145024] x27: 00bd24e0 file or 
directory
failed to loax26: 007fe00b74a0 d driver: sunxi
gbm: failed to 
open any driver (search paths /u[   21.159280] x25: 00bd1020 sr/lib/dri)
gbm: Last dlopen erx24: 0040a000 ror: /usr/lib/dri/kms_swrast_dri
.so: cannot open shared object f[   21.173552] x23: 007fe00b749c ile: No 
such file or directory
x22: 00bd24e0 failed to load driver: kms_swras
t
[12:24:33.498] EGL client ext[   21.187815] x21: 00be2190 ensions: 
EGL_EXT_client_extensiox20: 00be2080 ns
   EGL_EXT_platf
orm_base EGL_KHR_client_get_all_[   21.202076] x19: 00be2168 
proc_addresses
   Ex18: 0078 GL_KHR_debug EGL_EXT_platform_wa
yland EGL_MESA_platform_gbm
[12[   21.216342] x17: 007fa0b745c8 :24:33.499] warning: EGL_EXT_bufx16: 
007fa06e01f0 fer_age not supported. Performan
ce could be affected.
[12:24:33[   21.230619] x15: 0004 .499] warning: neither 
EGL_EXT_sx14: 007fa0b69cd0 wap_buffers_with_damage or EGL_K
HR_swap_buffers_with_damage is s[   21.244883] x13: 0a6c676520657a69 upported. 
Performance could be ax12: 6c616974696e6920 ffected.
[12:24:33.499] EGL_KHR
_surfaceless_context available
[   21.259142] x11:  [12:24:33.509] Failed to make EGx10: 
0101010101010101 L context current.
[12:24:33.50
9] EGL error state: EGL_BAD_MATC[   21.273416] x9 :  H (0x3009)
[12:24:33.509] EGL ex8 : 0039 rror state: EGL_SUCCESS (0x3000)


[12:24:33.512] failed to initi[   21.287684] x7 : 616974696e69206f alize egl
x6 : 007fa0b17580 
[   21.297353] x5 : 007fa0b17580 x4 : 00be2040 
[   21.303273] x3 :  x2 :  
[   21.309208] x1 :  x0 : 00be2380 
[   21.315133] 

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Weston at bootup

[Singh, Satyeshwar]

Hi Deepan,
Do you have any Weston logs when it restarts? Maybe you want to add --log 
option to redirect all output to some log file and share that with us?
-Satyeshwar

From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of deepan muthusamy
Sent: Friday, September 21, 2018 3:47 AM
To: Daniel Stone 
Cc: Andrea Giammarchi ; 
wayland-devel@lists.freedesktop.org
Subject: Re: Weston at bootup

Hi,

I tried the same thing in the link which you provided. It's starting but Weston 
is getting restart for every 90 sec.

My service file is as follows:

[Unit]
Description: launch Weston

Requires= dbus.socket dbus.service systemd-user-sessions.service

After= dbus.socket dbus.service systemd-user-sessions.service

[Service]
Type= notify
User=root
Restart=on-failure
ExecStart=/use/bin/Weston
PAMName=login
StandardInput=tty-fail
TTYPath=/dev/tty7
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
UtmpIdentifier=tty7
UtmpMode=user

[Install]
WantedBy=basic.target




"systemctl status launch Weston.service" gives

Account root has password changed in future.
Session opened for user root by root(uid=0)


What can be the possible reason?

On Tue, 18 Sep 2018, 9:59 pm Daniel Stone, 
mailto:dan...@fooishbar.org>> wrote:
Hi Deepan,

On Tue, 18 Sep 2018 at 17:24, deepan muthusamy 
mailto:deepan.m2...@gmail.com>> wrote:
Did you launched as session service?

I want to launch as system service. Have you tried that?

It sounds like you are having a problem, but there aren't enough details in 
your mails for us to help you. Have you already tried running it? There is an 
example systemd unit file given for running as a system service posted in this 
thread, which is the first Google hit for 'weston systemd': have you tried that?

https://lists.freedesktop.org/archives/wayland-devel/2017-November/035973.html

If this is not sufficient, please follow up with specifics of what you have 
actually tried, and how that is failing for you (what you expected to happen, 
what really happened, any log output, etc).

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel