09:51 pq: swick[m], maybe your MUA quotes the HTML version of the email you reply to, adding an extra newline every line. Anyway, it looks like EBU Tech 3320 pretty much answers all the questions we had about mastering display behaviour.
09:55 pq: I've recently understood how monitor adjustments can be taken into account in the color management model. It's simple really.
09:56 pq: The video signal should be targeted for such display and viewing environment the monitor is expecting. This may or may not be equivalent to the physical display capabilities and/or the actual viewing environment.
09:59 pq: This model allows the display to apply its own adjustments if it does so, without breaking the model.
10:01 pq: It also means clients will target the (potentially hypothetical) display and viewing environment the video signal is for, and not the actual display and environment directly.
10:03 pq: We do still need things like brightness adjustment in compositors, because one could plug in a display that displays the signal "as is" with hard clipping into hardware capability. It seems mastering displays are usually of this kind.
10:06 pq: Should the compositor adjustments be able to be bypassed... if one uses a display for mastering purposes, you don't want to screw that up.
10:09 pq: I think not. If you are mastering, all adjustments should be set to neutral, not bypassed. Compositors could even offer a "mastering mode" or a warning that custom adjustments are in effect.
10:09 pq: or would it be indicated by a rendering intent...
10:11 pq: ICC-absolute colorimetric rendering intent is still relative luminance, do we need one more rendering intent for truly absolute colorimetry (for signals that actually translate to absolute colorimetry: HLG and PQ)?
11:04 pq: oh hey, HDR finally gets rid of interlaced modes it seems. \o/
11:13 swick[m]: if the monitor expects a specific video signal, then yes, the right thing is to send that video signal and let the display do the adjustment to the actual display and actual viewing environment (this is mostly the user changing brightness settings)
11:14 swick[m]: the problems are 1. the display does not always expect a specific video signal (default mode), and 2. a lot of displays don't do any adjustment, and 3. some displays don't even let the user do any adjustments (especially true with PQ mode)
11:16 pq: yeah, that's why compositors will need the software adjustments anyway
11:17 pq: plus something that makes it easy for end users to opt out of any software adjustment
11:18 pq: swick[m], can you give an example of 1. btw.?
11:19 swick[m]: in the default mode displays expect no particular video signal
11:19 pq: default RGB colorimetry is supposed to match the EDID primaries, white point, and gamma, and luminance is adjusted in the display with contrast.
11:21 swick[m]: mh, so when the user changes the settings in default mode this is the display adjusting for the actual display in the actual viewing environment?
11:21 swick[m]: or rather only the viewing environment
11:21 pq: I would think so, yeah
11:22 swick[m]: okay, yeah, fair
11:22 swick[m]: I just feel like this is not a universally accepted interpretation, especially not by display manufacturers
11:23 pq: how so?
11:24 swick[m]: a lot of them don't let you change anything in PQ mode
11:24 swick[m]: and there are all kinds of special "look" transforms
11:26 pq: no adjustments in PQ mode: they probably pretend to be a reference display with locked settings, for the reference viewing environment - EBU Tech 3320 seems to warrant this. So we should just deal with them as "mastering displays" and have adjustments in the production (compositor).
11:27 swick[m]: there is also no setting specifically for countering surround brightness which increases display luminance and decreases colorfulness
11:27 pq: special look transforms: yeah, maybe not targeting any specific viewing environment, but they should still expect a specific kind of signal, so that the "look" is as the manufacturer intended.
11:28 swick[m]: pq: the problem then becomes differentiating between a mastering display and a "consumer" display
11:28 swick[m]: this is generally a problem: we don't know if the display does adjustments and we have to rely on the user telling us... which is not going to work out well
11:29 pq: differentiating that is left for the end user: if your monitor has the sufficient knobs, set your compositor to neutral.
11:30 pq: I don't think it really matters - what matters is that the end user is happy with the picture.
11:30 swick[m]: I agree in principle... not so sure how well this will work out
11:32 pq: If a compositor knew whether a display was adjustable or not, what difference would it make? If it's adjustable, you'd hide the compositor adjustments and lock them to neutral, perhaps?
11:35 pq: Would it not be good enough for the display settings dialog to say: First try checking the "neutral" box and adjusting your monitor. If you are not happy with that, then uncheck "neutral" and adjust here.
11:35 pq: and if it's an integrated laptop panel, you can probably assume there are no monitor adjustments
11:39 pq: countering surround brightness; that would be monitor brightness adjustment for luminance, but the loss of saturation is kind of unrecoverable. It essentially brings the primaries closer to the surround white point.
11:40 pq: you could boost signal saturation to mitigate it, but doing do, you make the input gamut respectively smaller.
11:41 pq: meaning the chromaticity clips earlier
11:44 pq: To have a surround brightness countering adjustment, you'd have to have a panel with much wider gamut than the standard signal you expect. Usually that's just wasting hardware capability, since usually the surround is not that harsh.
11:45 pq: given that BT.2020 uses monochromatic primaries, it's not even theoretically possible
11:53 pq: If compositor adjustments are intended to mitigate lack of adjustments in a monitor, then they should be applied as-if they were in the monitor. Which means that the output image description shall describe the target colorimetry *before* the adjustments.
11:53 pq: This seems very similar to VCGT.
11:54 pq: Compositor adjustments are essentially display calibration.
11:55 swick[m]: yup, but they always worse than the monitor doing it itself
11:55 pq: sure
11:55 pq: sometimes there is no choice
11:56 pq: What happens if you then measure such a setup to create an ICC profile... And set that display profile as your output image description...
11:56 swick[m]: in my ideal world we would have one UI to adjust the monitor and that either changes settings on the monitor directly or changes the signal to do the adjustment manually if the first method is not possible
11:57 pq: I think that Just Works. It's totally equivalent to VCGT in spirit.
11:57 swick[m]: yeah, seems fine... you just have to remember those settings in the profile and make sure they are actually applied
11:58 swick[m]: unfortunately we can't always make sure the display itself is configured the same way
11:58 swick[m]: another reason why all the configuration should always be available to the source
11:59 swick[m]: I really believe that at some point we have to go to VESA and try to convince them that we need a new certification for this
11:59 pq: Ideal indeed, would be nice. OTOH, people who profile and care, already know the caveats. We just need to make sure to not introduce new caveats.
12:01 swick[m]: the point here is that this doesn't have to be some arcane knowledge. this isn't an inherently complex system, it's just like this because displays are shit.
12:01 pq: sure
12:02 pq: I'm just acknowledging the current state and building for it, making sure it would also work in the ideal world.
12:03 pq: Once you get to the ideal world, it's "just" an UI change to make things simpler.
12:05 pq: I think a typical entertainment consumer would be just fine with the UI I described.
12:06 pq: I think there is a diagram I should be drawing...
12:10 marex: I have but a quick question, if I have multiple /dev/dri/cardN (and therefore multiple outputs), can weston DRM backend drive multiple of those from single compositor instance now or not yet ?
12:23 pq: marex, I think there is a command line switch for the additional cards today.
12:28 marex: pq: today is weston > 12.0.y ?
12:29 pq: probably? I haven't really looked into that feature myself.
12:30 marex: Options for drm:
12:30 marex: --drm-device=CARD The DRM device to use, e.g. "card0".
12:31 marex: I saw the multi output MRs btw
12:31 marex: that ^ is from current git HEAD
12:32 pq: it's --additional-device and looks like it's not documented
12:32 pq: err, --additional-devices
12:32 marex: pq: heh, I'll give it a try, thanks
12:32 marex: at least now I know what to grep for
12:33 pq: and yeah, it's in the 12 series
12:33 pq: as a new feature
12:36 marex: pq: yep, works, thanks !
12:36 pq: heh, cool
12:40 marex: pq: documentation MR is coming soon
12:40 pq: ooh!
12:42 wlb: weston Merge request !1359 opened by Marek Vasut (marex) backend-drm: document additional-devices parameter https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1359
12:46 marex: pq: I cannot just consume after all ... ^ docu MR done
12:46 pq: awesome!
12:47 marex: pq: thanks for the help
12:47 pq: that's why I'm here :-)
14:37 wlb: weston Merge request !913 closed (libweston: set the default presentation clock in weston_compositor_create())
17:38 bunni: I'm using weston in Buildroot, never really used weston/wayland much before this. Whenever I launch it, the XDG_RUNTIME_DIR only ever has a `wayland-1` socket being created, whereas if I don't have WAYLAND_DISPLAY set, most applications default to looking for `wayland-0` and then fail. Is there any reason why `wayland-1` is being used over -0 and/or is there any way to get the -0 socket set up on run?
17:54 psykose: the compositor also sets WAYLAND_DISPLAY
17:54 kennylevinsen: bunni: it is used to explicitly disable the automatic "guess" of wayland-0, as that has been considered a mistake
17:55 kennylevinsen: It causes significant issues, such as applications reaching out to a wrong display server
17:55 kennylevinsen: WAYLAND_DISPLAY must be set, and weston and other compositors does so before running configured commands/shell configuration
17:57 bunni: psykose, not when weston is launched from a shell in buildroot/busybox, unfortunately
17:57 bunni: kennylevinsen, thanks. Is there any easy way to get what the WAYLAND_DISPLAY should be other than scraping the RUNTIME dir manually to figure out the first socket?
17:58 kennylevinsen: (we couldn't remove the wayland-0 guess from the client library at the time as that would be a breaking change, but changing servers to start at wayland-1 broke no contract so that's what all servers did)
17:58 psykose: bunni: uhh, how do you start it?
17:58 bunni: `weston --tty 1 &`
17:58 bunni: serial console
17:58 bunni: not a virtual terminal
17:59 kennylevinsen: bunni: weston itself would WAYLAND_DISPLAY for its subprocesses, so you can read it from there
17:59 bunni: kennylevinsen, see my last couple of messages, it does not. Unless I'm starting it in an incorrect manner.
18:00 bunni: for its subprocesses, ah. Any way to get it from the launching process?
18:00 psykose: you can use --socket=name then
18:00 psykose: it sets WAYLAND_DISPLAY=name and puts that in runtime dir
18:00 psykose: you can pass it out of band to client env i guess
18:03 bunni: psykose, that might work. It sets WAYLAND_DISPLAY in any subprocesses, but that gives me a controlled and known name to set for any parents. I think that should get me where I need to be. Thanks
18:03 psykose: yes, normally all wayland clients you want to run will just be children and i haven't seen much of 'start a server in the background and later connect stuff to it', but that should let you do it
18:05 bunni: Its an embedded system that is meant to have most of its dev/testing done remotely from serial login (or ssh, etc.) so I'm trying to get something running on screen in a way that doesn't expect devs to need to plug in a keyboard and use the tiny 7" display
18:05 psykose: ahh
18:06 kennylevinsen: you can also use waypipe to stream the UI back if you want
18:07 bunni: kennylevinsen, is there a specific package/library that provides waypipe? Its not a standalone config option in buildroot and I don't see any suboptions that mention it. Buildroot isn't the best for finding applications buried in a "tools" or "utils" package.
18:11 bunni: ah, looks like its a separate tool. Yeah I might consider adding that. Thanks again!
18:11 psykose: it's called literally waypipe https://gitlab.freedesktop.org/mstoeckl/waypipe/
18:11 psykose: :)
19:11 wlb: weston Issue #814 opened by Walter Bonetti (IniterWorker) xwayland/window-manager does not provide a parent surface and all other ancestor surface https://gitlab.freedesktop.org/wayland/weston/-/issues/814
23:37 eyeris: Which wayland protocol allow applications to be paired together, either by surface embedding ala XEmbed or by asking the shell to treat two top level windows as one?
23:41 Company: is there even such a protocol?
23:42 Company: I know there's the external handle one that portals use, but they're just doign transient-for relationships afaik
23:44 eyeris: Foreign top-level handles? That one shows no compositor support on wayland.app
23:45 Company: https://wayland.app/protocols/xdg-foreign-unstable-v2