ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner has quit [Ping timeout: 480 seconds]
dviola has joined #wayland
Brainium has joined #wayland
Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
dcz_ has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
dcz_ has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
tent4052 has quit [Read error: Connection reset by peer]
tent405 has joined #wayland
Brainium has quit []
alarumbe has quit []
coldfeet has joined #wayland
kekekeks has joined #wayland
dcz_ has joined #wayland
kekekeks has quit [Ping timeout: 480 seconds]
kekekeks has joined #wayland
coldfeet has quit [Quit: Lost terminal]
coldfeet has joined #wayland
garnacho has joined #wayland
leon-anavi has joined #wayland
Tom^ has quit [Remote host closed the connection]
kekekeks has quit [Ping timeout: 480 seconds]
feaneron has quit [Ping timeout: 480 seconds]
Tom^ has joined #wayland
sima has joined #wayland
coldfeet has quit [Quit: Lost terminal]
kekekeks has joined #wayland
Sid127 has quit [Write error: connection closed]
Sid127 has joined #wayland
coldfeet has joined #wayland
Tom^ has quit [Remote host closed the connection]
Tom^ has joined #wayland
Tom^ has quit [Remote host closed the connection]
Tom^ has joined #wayland
alarumbe has joined #wayland
narodnik has joined #wayland
coldfeet has quit [Quit: Lost terminal]
alarumbe has quit []
alarumbe has joined #wayland
paulk-bis has joined #wayland
paulk has quit [Ping timeout: 480 seconds]
leon-anavi has quit [Read error: Connection reset by peer]
peeterm has quit [Quit: Leaving]
peeterm has joined #wayland
rasterman has joined #wayland
alarumbe has quit []
alarumbe has joined #wayland
<tokyovigilante>
are pending frame callbacks invalidated if a surface configure event occurs? I'm trying to debug my vulkan WSI app not rendering in fullscreen still, and running out of things to rule out
<emersion>
pending frame callbacks are never cancelled afaik
<emersion>
they accumulate in a queue, and at some point that queue is flushed and the events are sent
<emersion>
without a way to drop from the queue
<tokyovigilante>
ok thanks
coldfeet has joined #wayland
karenw has joined #wayland
leon-anavi has joined #wayland
chiku has joined #wayland
Sid127 has quit [Remote host closed the connection]
dcz_ has quit [Read error: Connection reset by peer]
dcz_ has joined #wayland
fmuellner has joined #wayland
Company has joined #wayland
coldfeet has quit [Quit: Lost terminal]
Moprius has joined #wayland
eroc1990 has joined #wayland
latex has quit [Remote host closed the connection]
latex has joined #wayland
<tokyovigilante>
Are there any DRM formats which are stored as UNORM? or is that a VkFormat only? ie is there a DRM_FORMAT_XXX equivalent of VK_FORMAT_B8G8R8A8_UNORM?
<kennylevinsen>
tokyovigilante: DRM formats don't concern themselves with whether your data is sRGB encoded or not - that's a matter of how you use the format afterwards
<kennylevinsen>
VK_FORMAT_XYZ_SRGB is a bit of a magic value that doesn't really change *format* as much as just inject automatic sRGB decoding when reading and sRGB encoding when writing for convenience
<kennylevinsen>
but a shader that encodes sRGB to a UNORM buffer would work just the same
<kennylevinsen>
TL;DR: yes it's a VkFormat thing because it does not change the storage, only how your Vulkan application reads/writes
<tokyovigilante>
ok, thanks, I'm still having problems with direct scanout with a vulkan VK_FORMAT_R8G8B8A8_UNORM swapchain on Sway just rendering a black/blank screen, no issues in a window
<kennylevinsen>
mixing up _UNORM and _SRGB would lead to distorted colors, not black
<kennylevinsen>
do you have an easy reproduction somewhere?
<kennylevinsen>
also did you check if sway debug log says something like failing import?
<tokyovigilante>
yup have experimented and found that
<kennylevinsen>
share a reproduction somewhere, will make it easier to discuss
<tokyovigilante>
not really, its a bit unwieldy as its a port from a GL renderer
<tokyovigilante>
and written in nim
<kennylevinsen>
:|
<tokyovigilante>
I have just realised my card is reporting a bunch of XRGB/ARGB formats, but not RGBA...
<kennylevinsen>
alpha should be disabled in direct scanout, so that would probably just lead to color channel swap (assumng you're not saturating just a single color channel that ended up landing in "X")
rasterman has quit [Quit: Gettin' stinky!]
<tokyovigilante>
don't think so, and its just rendering a clear colour and imgui currently
<kennylevinsen>
but yeah a minimal run of sway to collect the debug log and WAYLAND_DEBUG=1 of the application in the current state might be useful - for minimal you can just have a sway config that is just `exec 'WAYLAND_DEBUG=1 your_app 2>debug.log'\nexec 'sleep 10 && swaymsg exit'`, and then `sway -c your_config -d 2>sway.log`
atticf has quit [Remote host closed the connection]
<tokyovigilante>
Thanks, I'll try that, and its possibly suboptimal that it doesn't just fall back to composition if scanout fails, but I have just changed the swapchain format to VK_FORMAT_R8G8B8_UNORM (ie no alpha) and it's working :S
<tokyovigilante>
heres a debug log with a couple of fullscreen cycles of my client, not much to go on there.
<tokyovigilante>
Just a black screen when fullscreen, with no obvious issues. Good that just using a non-alpha swapchain works but odd that there's no validation layer or wayland warning etc
<kennylevinsen>
not the issue, but your swapchain looks like it's 7 buffers deep at the end which is quite a bit
<tokyovigilante>
thanks, the renderer does suck a bit, but I wanted to understand this issue before trying to rework the swapchain and fences etc, its largely just the imgui sample code refactored a bit currently
garnacho has quit [Remote host closed the connection]
<mahkoh>
vulkan color channels are written in the opposite order. so if your card only supports X/ARGB, then you have to use the B8G8R8A8 formats.
<kennylevinsen>
that shouldn't lead to black tho (assuming they have something in all color channels)
<mahkoh>
Why would the compositor try to call ADDFB2 if the IN_FORMATS array doesn't contain the format that the client is using for his buffers?
<mahkoh>
Ah, I don't know why it would lead to black.
<mahkoh>
I thought the issue was that he wasn't getting direct scanout.
<kennylevinsen>
no the weird thing is that we're "succeeding", but black screen :/
garnacho has joined #wayland
ramcq has joined #wayland
<kennylevinsen>
so it's XB24 with GFX11,64KB_R_X,PIPE_XOR_BITS=2,PACKERS=2,DCC,DCC_MAX_COMPRESSED_BLOCK=128B,DCC_INDEPENDENT_128B,DCC_PIPE_ALIGN - I wonder if there's just a driver bug for that combo on amdgpu
<kennylevinsen>
(DDC_RETILE is what amdgpu ends up preferring for gbm scanout buffers on my machine at least, so could just be a poorly tested combo)
Tom^ has quit [Remote host closed the connection]
<kennylevinsen>
tokyovigilante: just hacked up sway for a test, and at least on my GPU that format and modifier can be imported for composite but is rejected for scanout. However, on my setup it is properly rejected by the driver so sway stops trying direct scanout
<kennylevinsen>
neither XR24 nor XB24 can be scanned out with DDC_PIPE_ALIGN (what your buffers appear to be), but can be scanned out with DDC_PIPE_RETILE
<kennylevinsen>
but maybe you're on an older kernel or there's a bug specific to your device leading to the modifier being accepted even though it doesn't work
Orkoback27th[m] has joined #wayland
Calandracas_ has quit [Read error: Connection reset by peer]
Calandracas has joined #wayland
atticf has quit [Ping timeout: 480 seconds]
Tom^ has joined #wayland
feaneron has joined #wayland
qyliss has quit [Quit: bye]
qyliss has joined #wayland
coldfeet has joined #wayland
kekekeks has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kasper93 has quit [Remote host closed the connection]
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #wayland
<tokyovigilante>
kennylevinsen: wow, thanks for investigating. that’s really interesting. this is on my AMD laptop with iGPU but I see the same behaviour on my desktop (also AMD with a RDNA3 GPU). Both running Alpine edge so fairly current stacks.
<tokyovigilante>
interesting the imgui sample where I borrowed the vulkan boilerplate from works in full screen but that’s using Wayland via SDL so maybe not direct scan out, or choosing a different buffer. I might explore the imgui sample directly a bit and see what formats it’s using.
<emersion>
pq: yeldin is saying that the only difference between SDR and HDR-as-a-standard is the ability to punch through the brightness ceiling
<emersion>
but, isn't wide gamut (ability to expand beyond sRGB) also part of HDR somewhat?
<emersion>
or is that part of older standards?
<emersion>
for SDR, my understanding is that monitors can advertise wider gamuts via EDID, but still can't go too far off sRGB, because the input side has no way to indicate the gamut they're using?
<emersion>
and the input side often times just sends sRGB?
<emersion>
(also cc zamundaaa)
<zamundaaa[m]>
You can send BT2020 with the conventional SDR transfer function
<zamundaaa[m]>
It may be buggy on some monitors, but in principle, the brightness and color bits are separate features
<emersion>
yeah, but is that not part of "HDR"?
<emersion>
(as a standard)
<zamundaaa[m]>
HDR is a fuzzy marketing word
<emersion>
it is
<zamundaaa[m]>
So I wouldn't worry about it too much when it comes to displays... One of my laptops is marketed as "HDR" because its LCD can go up to a whopping 500 nits. It can't do anything else than conventional gamma 2.2 signaling
mahkoh has quit [Quit: WeeChat 4.6.3]
<zamundaaa[m]>
About SDR monitors with wider gamuts, they do very commonly just do much wider primaries anyways
<zamundaaa[m]>
Lots of OLED monitors give you native primaries in SDR mode too
<zamundaaa[m]>
The HDR mode just unlocks the brightness part
<emersion>
oh?
<emersion>
you mean, in SDR without special signalling you get as wide of a gamut as HDR?
<zamundaaa[m]>
Yes
<emersion>
you mean without setting BT2020?
iomari891 has joined #wayland
<emersion>
how does BT2020 get sent even, HDMI infoframe?
<zamundaaa[m]>
Yes. It's the reason for why so many people think everything looks dull with HDR enabled - they got used to the very oversaturated colors in SDR mode, and now they get proper sRGB
<emersion>
damn
<emersion>
i thought monitors were intentionally keeping their gamut close to sRGB in SDR mode
<emersion>
but it's worse than i thought
<zamundaaa[m]>
Nah, for marketing moar color = better
<emersion>
so in SDR mode, color values are kind of relative just like brightness, i suppose
<zamundaaa[m]>
What's even worse is that you sometimes get one behavior, sometimes the other
<emersion>
100% of red is whatever max the monitor supports
<zamundaaa[m]>
Some monitors do native primaries, but others do have an sRGB mode (which may or may not be default)
<emersion>
it's not sRGB red
<emersion>
interesting
<emersion>
oh, i see the "sRGB" option on my monitor now
<zamundaaa[m]>
This whole mess is part of the reason why artists need colorimeters. You can never be sure what the display actually does, unless you measure it yourself :/
<zamundaaa[m]>
Or get a much more expensive display with manufacturer guarantees or even built-in calibration of course
<emersion>
right, i thought it was just a bit off, but it sounds like it's arbitrarily far off
feaneron has joined #wayland
rv1sr has quit []
feaneron has quit [Read error: Connection reset by peer]
glennk has quit [Ping timeout: 480 seconds]
<kennylevinsen>
the curse of "vivid mode", the oldest monitor sales trick in the book
<kennylevinsen>
needs to stand out in the store
<kennylevinsen>
SDR content mapped to HDR have other quirks though, in particular in dark grays for some reason getting much lighter
akimoto has quit [Remote host closed the connection]
<kennylevinsen>
maybe SDR mapping should have configurable brightness/saturation to match user preference and panel capabilities better... things like Apple TV work around the issue by modesetting whenever content changes to match
<danieldg>
maybe something like the srgb 'rendering intent' field from PNG (Perceptual/Relative/Saturation/Absolute)
<danieldg>
tell people to use Saturation intent if they want their vivid mode :)
<zamundaaa[m]>
kennylevinsen: dark grays being brighter is only really a thing if either display or software are bad
<zamundaaa[m]>
It is a problem on Windows for example because they use the sRGB piece wise transfer function
<kennylevinsen>
it's also a problem on AppleTV, and I vaguely remember seeing it when playing with our HDR mode PRs on my oled laptop - my test usually bring the YouTube dark mode background turning light grey
<kennylevinsen>
but yeah maybe AppleTV does the same as Windows
<kennylevinsen>
IIRC, my laptop OLED panel just disables brightness control and boosts the max brightness when in HDR mode, and that's it :/