Re: HDR support in Wayland/Weston
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
Pekka Paalanen wrote:
> Graeme Gill wrote:
Hi,
>> I don't have any basis to voice an opinion as to which particular protocol
>> these different aspects would best fall into (wayland core or one of the
>> supplementary xdg protocols ? - I'm not clear on what the purpose of these
>> divisions is), I just know that they are intimately related, and development
>> of one without the other will risk mis-steps. I don't really understand
>> why you think they are orthogonal.
> color management related extensions would be neither Wayland core (in
> wayland.xml file) nor under the XDG umbrella (XDG is specific to
> desktops while color is not specific to desktops).
I understand that color management would be a Wayland extension protocol.
I'm not clear on whether color management tool support is specific to
desktops or not though.
> The Wayland upstream cannot force anyone to implement any
> extension. The upstream can offer design help, reviews, discussion
> forum and a repository to host extensions, which should make extensions
> popular among client software and suitable for more than one
> compositor. The pressure for someone to implement an extension only
> ever comes from the community: people wanting new things to work.
Sure.
> Color management related extensions would be several different
> extensions, each catering to its own scope. The one we are talking
> about here is for clients to be able to reasonably provide color
> managed content and enable the correct displaying of it under automatic
> adaptation to outputs. Other color management related extensions could
> allow e.g. measuring the color profiles of monitors, to be discussed at
> another time.
I disagree. They are two side of the same coin. They may well
be described by separate (but closely related) protocols, but
they should be designed and implemented together. This minimizes
the total amount of work involved, and ensures cohesion.
> Being able to provide color managed content implies knowing the color
> properties of the used hardware and images. It does not imply being
> able to measure the color properties:
Color properties of the display have to come from somewhere. Less work
overall, and a more secure result if the are measured in the way they
are intended to be.
> you don't re-measure the color
> properties continuously while using an application. Or if you actually
> do, we can cater for that use case when designing a measurement
> extension.
Users may choose to perform display calibration, profiling or verification
at any time. It may be once a year, once a month or once a day. They
may need to do it right now, just before they start a critical project,
or perhaps because they have altered some display setting (brightness,
contrast, color temperature, colorspace emulation mode.)
> I don't understand. How is a color profile, or say, an .icc file or
> whatever you use to store color profiles, dependent on the window
> system? Do you mean you cannot use the same profile data files on
> Windows and Linux X11?
It's unsafe to assume so. They may be identical, or they may not.
The conservative assumption amongst color critical users is that they
are not. As a color technologists I suspect they are often very
similar. Anecdotally people have reported differences.
(In the days of CRT's, they almost certainly differed with
different screen resolutions. Probably less so with modern
display technologies.)
In any case, expecting a user to boot up an alternate
operating system to do a color profile is pretty big ask,
and not something that is currently expected, and few will
be open to such an expectation. They will instead switch to
a system that doesn't require this of them.
> Or do you mean that the window system implementation adds its own
> unknown effect to the pixel values?
It's possible. The conservative assumption is to assume this might be
the case. ("conservative" in the sense of not wanting the uncertainty,
or having to waste time verifying that they are in fact identical.)
> If that is so, then the measuring
> environment on those systems is fundamentally broken to begin with.
Not at all. Any such processing is part and parcel of the effective
display characteristic. It has to be profiled as well, to end up
with a profile that is valid for that system.
>> It's unsafe to switch pixel pipelines in the process of characterization,
>> since it risks measuring transformations that happen/don't happen in
>> one context, and not in the other. It's also not something that
>> end users will put up with - if a system claims to support color management,
>> then it includes the color management tools necessary to setup,
>> maintain and verify its operation on a day to day basis.
>
> That seems like an unrealistic assumption, it kind of precludes the
> whole idea of interoperability. If your assumption is held, then you
> would need to make separate measurements for e.g. every single pixel
> format × color space an application
RE: [RFC 0/2] Add fp16 formats
Pekka Paalanen wrote: > On Mon, 4 Feb 2019 22:10:00 + "Strasser, Kevin" > wrote: > > That is what I was trying to achieve, offering applications fp16 scan > > out buffers. I'm not aware of any explicit requirement for adding the > > wl_shm format outside of Mesa's Walyand egl driver, which includes > > WL_SHM_FORMAT* for each supported visual (I think just for the swrast path). > > That should really be only the software rendering paths and they use wl_shm > specifically. > > The hardware rendering paths should use DRM formats (drm_fourcc), everything > is kind of standardising around those these days. Ok, I *think* we are on the same page. Once the drm formats have landed in the kernel we will add the equivalent to wl_shm (probably my first patch unless we decide on some other fourcc definition). This will make fp16 visuals available for hardware and software (swrast) paths in the egl driver. That should cover the requirements for use in Weston's gl renderer. Thanks, Kevin ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Limiting Xwayland to only one screen
Hi, I have a 2 screen configuration running Weston. When I run XWayland on top, it initially shows a black screen on both the screens. I am wondering if there is a way to limit XWayland to only using one screen? Is there a config file or command line option that allows me to do so? -Satyeshwar ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Upcoming release
Hi all, Thanks for reviewing, Daniel. I plan to update the MR with all changes after testing tomorrow. I hope that's fine. Cheers, Michael Michael Teyfel Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6932 > -Original Message- > From: wayland-devel On > Behalf Of Daniel Stone > Sent: Donnerstag, 31. Januar 2019 01:56 > To: Ucan, Emre (ADITG/ESB) > Cc: Pekka Paalanen ; Derek Foreman > ; wayland- > de...@lists.freedesktop.org > Subject: Re: Upcoming release > > Hi Emre, > > On Sat, 19 Jan 2019 at 20:39, Ucan, Emre (ADITG/ESB) jv.com> wrote: > > I would like to push XDG shell support for ivi-shell: > > https://gitlab.freedesktop.org/wayland/weston/merge_requests/86 > > > > It would be great if you and other maintainers can ack and/or review this > merge request till beginning of February. If they are no major concerns, it > would be great to have it in this release. > > I've reviewed this now, and there are only some minor changes I can see > need making. If Michael agrees with the suggested changes, I'm fine with > either him making the changes and updating the MR, or if he has no time this > week, I could just do it myself. I'd be really really glad to make > ivi_application > very deprecated. > > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] TODO: remove "SDL port", it's been done by now
On Fri, 10 Aug 2018 13:14:37 +0100 Eric Engestrom wrote: > Upstream SDL supports Wayland since v2.0.4 (June 2015): > https://forums.libsdl.org/viewtopic.php?t=11294 > > Just set SDL_VIDEODRIVER=wayland and SDL will do the right thing :) > > Signed-off-by: Eric Engestrom > --- > TODO | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/TODO b/TODO > index 8cb8d346ac73fa83a643..88fa5cc92b8a0be2a609 100644 > --- a/TODO > +++ b/TODO > @@ -102,9 +102,6 @@ Clients and ports > > - Investigate DirectFB on Wayland (or is that Wayland on DirectFB?) > > - - SDL port, bnf has work in progress here: > - http://cgit.freedesktop.org/~bnf/sdl-wayland/ > - > > Ideas > Ha. I wonder if the TODO has anything relevant anymore... Pushed: 6afb152..d7b0b79 master -> master Thanks, pq pgpbZxA2SP9IA.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland-web] xserver: how to let Weston find Xwayland
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: [RFC 0/2] Add fp16 formats
On Mon, 4 Feb 2019 22:10:00 + "Strasser, Kevin" wrote: > Pekka Paalanen wrote: > > is there a reason you need these in the wl_shm format list? That is, > > essentially for software rendered stuff? > > > > The zwp_linux_dmabuf extension which GL and Vulkan implementations are > > using only says the format is a drm_fourcc format, so there is no need > > to explicitly add the format there. > > > > Wayland does not need to support a pixel format for a compositor to be > > able to use that format on scanout/KMS. You only need the pixel format > > through Wayland if you want to have client buffers be able to hit the > > composite-bypass path and be scanned out directly on e.g. overlay or > > primary planes. > > That is what I was trying to achieve, offering applications fp16 scan out > buffers. I'm not aware of any explicit requirement for adding the wl_shm > format > outside of Mesa's Walyand egl driver, which includes WL_SHM_FORMAT* for each > supported visual (I think just for the swrast path). That should really be only the software rendering paths and they use wl_shm specifically. The hardware rendering paths should use DRM formats (drm_fourcc), everything is kind of standardising around those these days. > > wl_shm buffers are never expected to be scanout-capable because of the way > > their memory is allocated, so adding the format there does not help. > > zwp_linux_dmabuf is where the format is needed. > > > > Or do you need the formats for cursor planes? > > I don't believe fp16 would be needed for cursor planes. Right. Or maybe HDR cursors? Let's not go there yet. ;-) Thanks, pq > > Wayland and Pixman have no connection whatsoever. You don't need > > support in Pixman to have these added into wl_shm set of formats. > > > > Implementing compositor support for them may or may not need Pixman > > support, depending on the compositor. Weston for example has two > > renderers, and the GL-renderer could well support these formats without > > Pixman supporting them. The Pixman renderer OTOH could not. Weston's > > renderers are allowed to support different sets of formats, so Pixman > > support is not necessary for Weston support. > > > > As a small detail, patch 2 is ok, but not necessary. Those tests test > > wayland-scanner, and adding this new format to example.xml does not > > really add anything to the test. > > Ok, thanks for the detailed explanation. > > Thanks, > Kevin pgpTy8uzJlDJa.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
