ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
sevz has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Avenaire1 has joined #wayland
Avenaire has quit [Ping timeout: 480 seconds]
Avenaire1 is now known as Avenaire
cool110 has joined #wayland
Guest876 has quit [Remote host closed the connection]
cool110 is now known as Guest897
colemickens has quit [Quit: Connection closed for inactivity]
Guest897 has quit [Remote host closed the connection]
cool110_ has joined #wayland
cool110_ is now known as Guest898
Avenaire has quit [Remote host closed the connection]
Avenaire has joined #wayland
Guest898 has quit [Remote host closed the connection]
sjao2 has quit [Quit: WeeChat 3.4.1]
cool110 has joined #wayland
cool110 is now known as Guest902
mxz has quit [Quit: cya]
fgdfgdfgd has joined #wayland
mxz has joined #wayland
mblenc1 has joined #wayland
sevz has quit [Quit: WeeChat 4.0.4]
sima has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
sevz has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
jtbx has quit [Remote host closed the connection]
nnm- has joined #wayland
manuel__ has joined #wayland
manuel_ has quit [Read error: Connection reset by peer]
jtbx has joined #wayland
nnm has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Read error: No route to host]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
bodiccea has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
sjao2 has joined #wayland
pochu has joined #wayland
iomari892 has joined #wayland
Guest902 has quit []
cool110 has joined #wayland
cool110 is now known as Guest921
shankaru has joined #wayland
slim has quit [Quit: slim]
sevz17 has joined #wayland
slim has joined #wayland
sevz has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
Avenaire1 has joined #wayland
Avenaire1 has quit []
Avenaire has quit [Ping timeout: 480 seconds]
cmichael has joined #wayland
mbalmer has quit []
rasterman has joined #wayland
cptaffe` has joined #wayland
cptaffe has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
mblenc has joined #wayland
mbalmer has joined #wayland
fmuellner has joined #wayland
<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.
<pq>
I've recently understood how monitor adjustments can be taken into account in the color management model. It's simple really.
<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.
<pq>
This model allows the display to apply its own adjustments if it does so, without breaking the model.
<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.
<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.
<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.
<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.
anarsoul has quit [Remote host closed the connection]
anarsoul has joined #wayland
<pq>
or would it be indicated by a rendering intent...
<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)?
privacy has quit [Quit: Leaving]
nerdopolis has joined #wayland
neniagh_ has joined #wayland
neniagh has quit [Ping timeout: 480 seconds]
<pq>
oh hey, HDR finally gets rid of interlaced modes it seems. \o/
cstub has joined #wayland
colemickens has joined #wayland
<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)
<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)
<pq>
yeah, that's why compositors will need the software adjustments anyway
<pq>
plus something that makes it easy for end users to opt out of any software adjustment
<pq>
swick[m], can you give an example of 1. btw.?
<swick[m]>
in the default mode displays expect no particular video signal
<pq>
default RGB colorimetry is supposed to match the EDID primaries, white point, and gamma, and luminance is adjusted in the display with contrast.
<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?
<swick[m]>
or rather only the viewing environment
<pq>
I would think so, yeah
<swick[m]>
okay, yeah, fair
<swick[m]>
I just feel like this is not a universally accepted interpretation, especially not by display manufacturers
<pq>
how so?
<swick[m]>
a lot of them don't let you change anything in PQ mode
<swick[m]>
and there are all kinds of special "look" transforms
<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).
<swick[m]>
there is also no setting specifically for countering surround brightness which increases display luminance and decreases colorfulness
<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.
<swick[m]>
pq: the problem then becomes differentiating between a mastering display and a "consumer" display
<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
<pq>
differentiating that is left for the end user: if your monitor has the sufficient knobs, set your compositor to neutral.
<pq>
I don't think it really matters - what matters is that the end user is happy with the picture.
<swick[m]>
I agree in principle... not so sure how well this will work out
<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?
<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.
<pq>
and if it's an integrated laptop panel, you can probably assume there are no monitor adjustments
<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.
<pq>
you could boost signal saturation to mitigate it, but doing do, you make the input gamut respectively smaller.
<pq>
meaning the chromaticity clips earlier
mvlad has joined #wayland
<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.
<pq>
given that BT.2020 uses monochromatic primaries, it's not even theoretically possible
Moprius has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
<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.
<pq>
This seems very similar to VCGT.
<pq>
Compositor adjustments are essentially display calibration.
nerdopolis has joined #wayland
<swick[m]>
yup, but they always worse than the monitor doing it itself
<pq>
sure
<pq>
sometimes there is no choice
<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...
<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
<pq>
I think that Just Works. It's totally equivalent to VCGT in spirit.
<swick[m]>
yeah, seems fine... you just have to remember those settings in the profile and make sure they are actually applied
<swick[m]>
unfortunately we can't always make sure the display itself is configured the same way
<swick[m]>
another reason why all the configuration should always be available to the source
<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
<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.
<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.
<pq>
sure
<pq>
I'm just acknowledging the current state and building for it, making sure it would also work in the ideal world.
<pq>
Once you get to the ideal world, it's "just" an UI change to make things simpler.
<pq>
I think a typical entertainment consumer would be just fine with the UI I described.
<pq>
I think there is a diagram I should be drawing...
<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 ?
<pq>
marex, I think there is a command line switch for the additional cards today.
<marex>
pq: today is weston > 12.0.y ?
<pq>
probably? I haven't really looked into that feature myself.
<marex>
Options for drm:
<marex>
--drm-device=CARD The DRM device to use, e.g. "card0".
<marex>
I saw the multi output MRs btw
<marex>
that ^ is from current git HEAD
<pq>
it's --additional-device and looks like it's not documented
<marex>
pq: I cannot just consume after all ... ^ docu MR done
<pq>
awesome!
<marex>
pq: thanks for the help
<pq>
that's why I'm here :-)
nerdopolis has joined #wayland
ZhangTingAn has joined #wayland
Lihua has quit [Read error: Connection reset by peer]
neniagh_ has quit []
neniagh has joined #wayland
lbia has quit [Quit: lbia]
Moprius has quit [Quit: bye]
lbia has joined #wayland
cstub has quit [Read error: Connection reset by peer]
junaid has joined #wayland
<wlb>
weston Merge request !913 closed (libweston: set the default presentation clock in weston_compositor_create())
rgallaispou has left #wayland [#wayland]
rv1sr has joined #wayland
kts has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
kts has quit [Ping timeout: 480 seconds]
mohit815 has quit [Quit: mohit815]
mohit815 has joined #wayland
tzimmermann has quit [Quit: Leaving]
mohit815 has quit [Quit: mohit815]
mohit815 has joined #wayland
Sachiel_ has joined #wayland
cptaffe has joined #wayland
cptaffe` has quit [Ping timeout: 480 seconds]
Sachiel has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
Guest921 has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest952
mvlad has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mblenc has joined #wayland
mblenc1 has joined #wayland
rv1sr has quit []
mblenc has quit [Read error: No route to host]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
mblenc1 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mblenc has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
bunni has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
Sachiel_ has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
<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?
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
<psykose>
the compositor also sets WAYLAND_DISPLAY
<kennylevinsen>
bunni: it is used to explicitly disable the automatic "guess" of wayland-0, as that has been considered a mistake
<kennylevinsen>
It causes significant issues, such as applications reaching out to a wrong display server
<kennylevinsen>
WAYLAND_DISPLAY must be set, and weston and other compositors does so before running configured commands/shell configuration
mblenc1 has quit [Ping timeout: 480 seconds]
<bunni>
psykose, not when weston is launched from a shell in buildroot/busybox, unfortunately
<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?
<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)
<psykose>
bunni: uhh, how do you start it?
<bunni>
`weston --tty 1 &`
<bunni>
serial console
<bunni>
not a virtual terminal
<kennylevinsen>
bunni: weston itself would WAYLAND_DISPLAY for its subprocesses, so you can read it from there
<bunni>
kennylevinsen, see my last couple of messages, it does not. Unless I'm starting it in an incorrect manner.
<bunni>
for its subprocesses, ah. Any way to get it from the launching process?
<psykose>
you can use --socket=name then
<psykose>
it sets WAYLAND_DISPLAY=name and puts that in runtime dir
<psykose>
you can pass it out of band to client env i guess
<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
<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
<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
<psykose>
ahh
<kennylevinsen>
you can also use waypipe to stream the UI back if you want
<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.
<bunni>
ah, looks like its a separate tool. Yeah I might consider adding that. Thanks again!
<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?
<Company>
is there even such a protocol?
<Company>
I know there's the external handle one that portals use, but they're just doign transient-for relationships afaik
tesjhg has joined #wayland
<eyeris>
Foreign top-level handles? That one shows no compositor support on wayland.app