02:55wlb: wayland Merge request !397 opened by Joaquim Monteiro (jmonteiro) meson: Fix use of install_data() without specifying install_dir https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/397
09:03nomanLLy: hi guys. i have a laptop and external monitor. i want to output of the monitor to be identical to the laptop. is this possible with wayland? in Xorg i used to do it with `xrandr --output HDMI-1 --same-as eDP1`
09:28d_ed[m]: it is possible in wayland, the mechanism to do that depends on your desktop
09:28d_ed[m]: and is best to ask in the channel of your respective desktop (gnome, sway, etc.)
11:34wlb: weston Issue #915 opened by Pekka Paalanen (pq) New output configuration design for the frontend https://gitlab.freedesktop.org/wayland/weston/-/issues/915 [Weston frontend], [Core compositor]
11:35wlb: wayland-protocols Merge request !318 opened by Simon Ser (emersion) readme: recommend using "Draft:" prefix for RFC protocols https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/318
13:07pq: CTA-861-H section 5.3 Transfer Characteristic is really interesting... the default colorimetry seems to point to BT.709 TF which points to BT.1886 TF which uses gamma=2.4. Not 2.2. What am I missing?
13:08wlb: wayland Merge request !398 opened by Julian Orth (mahkoh) protocol: buffer storage must not be destroyed while in use https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/398
13:10pq: 1 / 0.45 = 2.22, but that's the OETF, not assumed EOTF
13:18pq: hmm, maybe Colorimetry Transfer Characteristics table in CTA-861-H has a typo. The first row should be BT.709, not RGB.
13:19pq: because colorimetry = "no data" is a possibility, and colorimetry = BT.709 seems to be missing from the table.
13:29vsyrjala: bt.709 is in row 6 with that other guy
13:29pq: huh, so it is
13:30pq: ooh
13:30pq: CTA-861-I has more rows!
13:30pq: so we have separate rows for RGB, sRGB, and defaultRGB now
13:30JEEB: yea, and thankfully CTA specs you can get for free as long as you fill in Trollgatan 32, Stockholm or something as your location and a@b.c as email
13:31JEEB: (or at least CTA-861 was such)
13:31pq: you mean one needs to fill in a form for no reason, yes
13:32JEEB: yup
13:32pq: rather than those are a secret hand-shake to drop the fees :-)
13:33JEEB: oh, they have added more validation to it now
13:33vsyrjala: and the fricking filename changes format every time!
13:33JEEB: at least requires a valid domain
13:36JEEB: pq: I wish I knew the secret handshakes ;) I would otherwise have access to the IEC audio channel definition spec
13:40vsyrjala: hmm. defaultRGB seems to be a new thing. signalled via the ACE bits
13:55pq: so defaultRGB is nothing about any default?
13:56pq: uhhh, and sRGB also has explicit ACE bits
13:57pq: so, when Colorimetry says "No Data", which row of the Colorimetry Transfer Characteristics table applies?
13:58pq: the first one, RGB? which implies gamma 2.4?
14:02pq: have we been feeding sRGB images to gamma 2.4 displays all this HDMI and DP time?
14:04pq: or maybe "No Data" means "anything goes", and... the RGB row in the table is... useless?
14:07zamundaaa[m]: Idk about the specs, but displays definitely do roughly gamma 2.2 if you measure them, not 2.4
14:09pq: yeah, the spec confuses me
14:10vsyrjala: the spec seems to imply that section 5.1 should be defining some kind of default colorimetry for the "no data" case, but i see nothing like that there
14:17vsyrjala: If the Colorimetry bits C0 and C1 in the AVI InfoFrame are
14:17vsyrjala: both zero (indicating “No Data”), then the transfer function shall be consistent with the
14:17vsyrjala: requirements in Section 5.1, “Default Encoding Parameters”.
14:17vsyrjala: but section 5.1 doesn't even mention the transfer function
14:17pq: \o/
14:18pq: can I hardcode "Assumed gamma 2.2" then?
14:21swick[m]: The "no data" case is really undefined, that's why we have defaultRGB which properly defines what the "no data" thing was supposed to be
19:05vyivel: is input-timestamps-unstable-v1 used by any clients?