ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
dreda has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
immibis has quit [Read error: Connection reset by peer]
slattann has joined #wayland
ahartmetz has quit [Quit: Konversation terminated!]
juwain has quit [Quit: Connection closed for inactivity]
Company has quit [Quit: Leaving]
Moprius has quit [Quit: Konversation terminated!]
floof58 has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
floof58 has joined #wayland
hill has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
fluix has left #wayland [#wayland]
hill has quit []
dcz_ has joined #wayland
caveman has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
slattann1 has joined #wayland
slattann has quit [Ping timeout: 480 seconds]
ecloud_ has quit []
ecloud has joined #wayland
jgrulich has joined #wayland
hardening has joined #wayland
mbalmer has joined #wayland
danvet has joined #wayland
rgallaispou has joined #wayland
rasterman has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
mclasen has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
___nick___ has joined #wayland
<pq>
danieldg, yes, you will be able to change the color space, which means you can almost arbitrarily change what any particular r,g,b number tuple means.
<pq>
danieldg, if you first define that your color space in one thing, and then you want to encode colors *outside* of that color space (volume), then you would need negative and greater than 1.0 pixel values.
<pq>
*is one thing
<pq>
That's one way to think about it, but also enough to see IMO that needing values outside of the [0.0, 1.0] is almost always avoided by choosing your encoding intentionally.
<pq>
that applies to storage
immibis has joined #wayland
<dv_>
is there a use case at all for values beyond 1.0? IIRC, the main use would be some sort of tone mapping.
<dv_>
and that's done in games (inside their 3d engines), inside cameras, and in photo editing applications when they get raw pictures from cameras. none of these involve the compositor.
ahartmetz has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
<pq>
dv_, depends on how you define things. E.g. scRGB color space by definition makes use of negative and greatere than 1.0 values. But one could still map those to uint32_t.
<pq>
Everyone just needs to be on the same page on how the values are scaled and offsetted.
<pq>
dv_, compositors will be doing tone-mappings of their own, too, particularly when you drive a monitor in some HDR mode. Not all applications will adjust to the monitor, some will just use standardized color spaces.
Company has joined #wayland
kchibisov has quit [Read error: Connection reset by peer]
devilhorns has joined #wayland
kchibisov has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
dcz_ has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
<LaserEyess>
pq: is there any hardware acceleration of that tonemapping? I'm wondering if there's a way to just fake HDR metadata to the display and have it display "HDR" instead of using a shader. I know some displays have "HDR mode" that will "work" even with SDR and I'm wondering if they're actually doing something besides turning up the saturation and brightness
<LaserEyess>
granted, I would not trust any such tonemapping to be good, but for things that have really bad GPUs I wonder if it's possible
<pq>
LaserEyess, "good", as in, "may or may not actually do *anything*" ;-)
Dami_Lu has joined #wayland
<pq>
For example, HDR static metadata has a couple fields for max luminance. Testing on my HDR monitor, it seems is does: if (L > 100) make_it_really_bright(); else make_it_look_like_any_old_monitor();
<LaserEyess>
yeah I mean, I have an VESA Certified™ HDR monitor and when I used windows 10 in HDR mode all it did was... turn up the brightness
<pq>
as for hw accel, look at KMS UAPI - that's what we have available
<pq>
making up HDR metadata to achieve a desired tone mapping, I don't really believe in.
<pq>
at most we can relay video metadata to the monitor when it plays fullscreen
<pq>
hoping that the video uses such metadata values that are listed in some standard and that the monitor vendor cared about the same standard
<LaserEyess>
there's no standard of metadata?
<LaserEyess>
that sounds troubling
<pq>
sure there are standards, but you'd need video makers and monitor vendors care about them :-)
<LaserEyess>
>Userspace will be responsible to do Tone mapping operation in case:
<LaserEyess>
>Some layers are HDR and others are SDR
<LaserEyess>
>HDR layers luminance is not same as sink
<LaserEyess>
ok so pretty much what I suggested is not supported
<LaserEyess>
meh, if your GPU is shit you shouldnt' care about HDR anyway
<pq>
I never said GPU
<LaserEyess>
you didn't, but I did
<LaserEyess>
after all where else is the tonemapping shader going to run?
<pq>
note, "being responsible" does not mean "implement in shaders", it can also mean "program more KMS state to achieve it"
<LaserEyess>
I only started looking at the KMS docs about 10 minutes ago but I don't see any sort of KMS property that could help with that
<pq>
For example, you can kinda get fairly far I believe by using the per-plane LUT/CTM/LUT pipeline in converting SDR to HDR or HDR to SDR before blending.
<pq>
not the best results perhaps, but maybe ok'ish if your GPU is too weak
<pq>
oh, but I'm not sure those props are quite upstream yet
<LaserEyess>
if these docs are up to date it seems they are
<pq>
anyway, that's the idea: you don't tell KMS "this is SDR, tone it for HDR monitor". Instead you tell KMS "use this matric and this array for the LUT".
<emersion>
these are not per-plane
<LaserEyess>
oh
<emersion>
they are per-CRTC
<emersion>
the per-plane stuff is not merged yet
<pq>
yeah, CRTC degamma/ctm/gamma are similar but they happen after blending, not before.
<LaserEyess>
nevermind then, like I said I just started reading those docs 10 minutes ago and it's not like I understand them anyway
<LaserEyess>
good to know that this sort of thing is being worked on though
<pq>
worked on by not-me, I just complain :-)
<pq>
and sometimes review
<LaserEyess>
more than I do, so thanks
<pq>
The idea I've been driving is that we want to tell KMS what operations to apply to pixels, and that userspace will then come up with the needed operations based on what the color characteristics of all things are.
<pq>
So userspace is resposible of coming up with the correct tone-mapping, but KMS could be used to apply that tone-mapping.
<pq>
and when KMS doesn't bend to it, userspace can do it shaders
<pq>
*do it in shaders
<pq>
tone-mapping or color space conversion or color model conversion or whatever ^
<LaserEyess>
personally, I'd start with the shaders :)
<pq>
that's what we are doing with Weston
<pq>
shaders first, KMS then when it happens to fit
<LaserEyess>
neat
<pq>
what I've learnt most recently is that computational precision can be a b... problem.
<pq>
often you have to approximate one thing with another and that raises practical problems
<pq>
one of those problems is being solved by introducing "segmented LUT" concept in KMS UAPI
<dv_>
so, support through KMS essentially means "potentially better performance due to dedicated hardware but also impossible to guarantee accuracy"
<pq>
pretty much
<pq>
I mean, if you do roughly standard things with the KMS hardware, I'd expect roughly standard precision. The hardware can't suck too bad, or no-one will buy it.
immibis has quit [Remote host closed the connection]
<pq>
maybe the same could be said about HDR static metadata sent to a monitor, with a much much narrower scope of "roughly standard things".
<pq>
it's when you get creative that may be a problem
<dottedmag>
How is HDR metadata sent to monitor? Is it some kind of a side-channel?
<dottedmag>
I'm mostly curious about DisplayPort.
<pq>
dottedmag, kinda, both HDMI and DP has something to deliver standard non-pixel data to sinks.
<emersion>
"infoframes"
<pq>
those
<dottedmag>
thanks
<pq>
in KMS, you set the values you want in a property, and the driver then keeps on sending that to the sink until someone says otherwise
<pq>
...which is how I get fbcon into HDR mode x_x
agd5f has joined #wayland
<pq>
emersion, these two test EDIDs in CI make me feel like I could just hit merge on all your MRs without ever checking up on the spec. :-)
<emersion>
ahah
<emersion>
maybe should wire up coverage info as well for extra merge feelings
<pq>
that would be nice
<pq>
also add more EDIDs to CI?
jgrulich has quit [Remote host closed the connection]
immibis has joined #wayland
c7s has joined #wayland
EmetSelch has joined #wayland
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #wayland
devilhorns has quit []
mbalmer has quit []
devilhorns has joined #wayland
ybogdano has joined #wayland
rgallaispou has quit []
fmuellner has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
fmuellner has quit [Remote host closed the connection]
___nick___ has quit []
___nick___ has joined #wayland
<zubzub>
Ok so I checked wl_drm support in Weston using protocol logging etc. and it all seems to work just fine. I think the reason it's not working with my implementation is that I'm using a forked libwayland-server, while the mesa links to the system libwayland-server.
jgrulich has joined #wayland
<zubzub>
I see in the protocol tracing that not formats are advertised after binding to the wl_drm global
<zubzub>
*no formats
<zubzub>
while in weston this appens immediately after binding to the drm global
slattann1 has quit [Ping timeout: 480 seconds]
mclasen has quit []
mclasen has joined #wayland
Narrat has joined #wayland
devilhorns has quit []
ybogdano has quit [Ping timeout: 480 seconds]
hergertme has quit [Remote host closed the connection]
hergertme has joined #wayland
jgrulich has quit [Remote host closed the connection]