Wayland windows' colors are too dark

[johanhelsing]

breakout-wayland.log

• kwin
• bevy: cb4e8c8
• Nvidia GTX 970

[JMS55]

Bloom has known issues with transparency, which will be fixed by #6677.

The lightness shift is interesting though.

[johanhelsing]

Alright, removing bloom from the title to keep the issue focused.

For what it's worth, I tested on gnome as well, and it's behaving the same, so likely not a compositor bug.

wayland on the left, x11 on the right

The colors on X11 are consistent with what I see on Windows and wasm, (just confirming it's wayland that is off, and not x11)

[johanhelsing]

From the wayland logs, it looks like we're creating the right kind of surface:

[1036841.262]  -> wl_surface@18.frame(new id wl_callback@43)
[1036841.622]  -> zwp_linux_dmabuf_v1@45.create_params(new id zwp_linux_buffer_params_v1@51)
[1036841.633]  -> zwp_linux_buffer_params_v1@51.add(fd 51, 0, 0, 5120, 50331648, 5234708)
[1036841.639]  -> zwp_linux_buffer_params_v1@51.create_immed(new id wl_buffer@54, 1280, 720, 875713089, 0)
[1036841.644]  -> zwp_linux_buffer_params_v1@51.destroy()

We're creating a surface with the 875713089 format, which is AR24 in fourcc (ARGB8888)

I'm not really sure how to dig further. I took some RUST_LOG=debug logs from running the breakout example as well. Let me know if there's any other way I can help.

breakout-debug-wayland.log

EDIT: I tried bisecting. And on v0.8.0, I got:

2023-01-21T23:31:47.426572Z  INFO bevy_render::renderer: AdapterInfo { name: "NVIDIA GeForce GTX 970", vendor: 4318, device: 5058, device_type: DiscreteGpu, backend: Vulkan }
thread 'main' panicked at 'Error in Surface::configure: requested format Bgra8UnormSrgb is not in list of supported formats: [Bgra8Unorm]', /home/johan/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.13.1/src/backend/direct.rs:281:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It stopped panicking on startup in f5322cd. That commit message explains the weird behavior. We're just choosing ARGB8888 even though the image we produce probably is srgb.

[Elabajaba]

So we should be able to fix this once we land wgpu 0.15, but it requires using texture_views on non-srgb surfaces (and we should still default to srgb surfaces if they're available).

The problem is I wasn't able to get them working without a ton of vulkan validation errors, so I opted out of it for that PR.

[JMS55]

@Elabajaba the recently released wgpu 0.15.1 should fix this. Do you mind taking another stab at it?

[VitalyAnkh]

@JMS55 I found the color is still too dark on Wayland with the lasted commit (eaac730) which contains wgpu 0.15.1 update:
On Wayland:

RUST_BACKTRACE=1 RUST_LOG=info WGPU_BACKEND=vulkan cargo run --features wayland --example fog

and on X11:

RUST_BACKTRACE=1 RUST_LOG=info WGPU_BACKEND=vulkan cargo run --example fog

[Hellzbellz123]

bug exists on nvidia-dkms it seems. testing nvidia-open-dkms to see if there is a difference.
no change on nvidia-open-dkms
nvidia-dkms/525.89.02 with an RTX 3070 lhr
running cachyos linux kernel 6.1.12-1
running said apps with wayland and using swrast/lavapipe gets me the correct colors so that leads me to believe its a driver issue, while testing this i also discovered that the bloom example has a bug where the window is transparent when intensity is postive
xorg:

wayland:

[VitalyAnkh]

So this problem only happens on NVIDIA's GPU? Are there any similar issues on Intel or AMD?

I'm also using nvidia-dkms-open and experiencing this problem.

[Elabajaba]

So this problem only happens on NVIDIA's GPU? Are there any similar issues on Intel or AMD?

I'm also using nvidia-dkms-open and experiencing this problem.

Afaik Nvidia's Linux driver kinda sucks and doesn't support sRGB surface formats.

I'll try and get a pr up tomorrow to use an srgb texture view when the surface format isn't srgb now that it was fixed on the wgpu side.