Warped and Grayscaled image on some integrated displays

[rezaamashi]

I am running the latest git version from AUR, but the 0.9.5-1 from AUR also have the same issue.

The wallpaper is "warped" and if I change the image with animation the whole WM, in my case Hyprland, will crash. Regarding the "warped" image, I also tried to use swaybg, and the issue is gone. So maybe it is a problem with swww.

Currently I am using swww as it is and set the --transition none for no animation.

Thanks

[Day-OS]

Having the exact same issues also using swww 0.9.5-1 from AUR (This is a two monitor setup)

It is also very likely to crash during wallpaper changes. I got some logs of it crashing, here it is:

03:45:30 [INFO] (main) Selected wl_shm format: Bgr888
03:45:30 [INFO] (main) Initialization succeeded! Starting main loop...
03:45:30 [WARN] (main) Received transform. We currently ignore those
03:45:30 [WARN] (main) Received transform. We currently ignore those
9052 8582
03:45:30 [WARN] (cache loader) failed to load cache: there is already another swww process running
9052 8582
03:45:30 [WARN] (cache loader) failed to load cache: there is already another swww process running
03:45:31 [INFO] (transition) BumpPool with: 1 buffers. Size: 3796Kb
03:45:31 [INFO] (transition) BumpPool with: 1 buffers. Size: 3073Kb
03:45:31 [INFO] (transition) BumpPool with: 2 buffers. Size: 7593Kb
03:45:31 [INFO] (transition) BumpPool with: 2 buffers. Size: 6147Kb
Io error: Connection reset by peer (os error 104)
thread 'main' panicked at daemon/src/main.rs:191:30:
Io error when reading wayland events: Connection reset by peer (os error 104)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
03:45:35 [INFO] (main) Removed socket at "/run/user/1000/swww-wayland-1.socket"

[LGFae]

For the wrapped image, try starting swww-daemon with swww-daemon --format

[rezaamashi]

Yep. that seems to be the solution.

However, playing around with the --format flag: rgb returns:

       0ms [INFO]  (main) Forced usage of wl_shm format: Rgb888
       2ms [INFO]  (main) Initialization succeeded! Starting main loop...
       3ms [WARN]  (main) Received transform. We currently ignore those
     185ms [INFO]  (transition) BumpPool with: 1 buffers. Size: 3073Kb
Protocol error 0 on object wl_shm_pool@15: Unsupported format
thread 'main' panicked at daemon/src/main.rs:193:25:
Protocol error 0 on object wl_shm_pool@15: Unsupported format
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
     192ms [INFO]  (main) Removed socket at "/run/user/1000/swww-wayland-1.socket"

As in @Day-OS stacktrace, bgr seems to be the situation where the wallpaper is "warped" and crashing on image change. And both xbgr and xrgb where it works as expected, ie. image not warped and image change with transition works.

[rezaamashi]

After a short glance on the README, I reckon that similar issue already touched upon in #233. I didn't see it since it was closed, although the issue persists.

Is the currently proposed workaround, using --format flag with either xrgb or xbgr, is the final solution? or is there a fix underway? If the former is the case I'd be willing to just close this issue. Otherwise, having this issue open; or reopening appropriate past similar issue, I believe, could help prevent people create further duplicate issues.

[LGFae]

However, playing around with the --format flag: rgb returns:

This is expected, very few compositors in my experience support rgb format. When you pass it as an command line option we try to force it anyway, generating a protocol error, as you can see from what was printed.

And both xbgr and xrgb where it works as expected, ie. image not warped and image change with transition works.

Interesting. Thanks for that. I really do think this is like, a Mesa bug at this point, but I could be wrong. Because it only fails in certain hardware or configurations. For example, do you by any chance have an integrated display (like in a notebook)?

Is the currently proposed workaround, using --format flag with either xrgb or xbgr, is the final solution? or is there a fix underway? If the former is the case I'd be willing to just close this issue. Otherwise, having this issue open; or reopening appropriate past similar issue, I believe, could help prevent people create further duplicate issues.

Let's leave this open for now, I will rename it though to better reflect what's going on.

The reason I closed the previous issue was that, while working on fractional scaling support (note I had never succeeded in reproducing the issue up to that point), I came across this same problem myself, and thought "ah, so THIS is what everyone's been facing". After I fixed it, I thought the problem would have been fixed for everyone, and closed the previous issue. No one said anything, and I was happy about it.

Now I realize no one said anything probably because everyone added --format xrgb to their config and didn't bother changing it back, so it still worked.

EDIT: the fact that the compositor crashes further corroborates my hypothesis this is a full-blown mesa bug, now that I think about it.

[rezaamashi]

Let's leave this open for now, I will rename it though to better reflect what's going on.

Please do, whichever name that you feel more apt, while also help people to relate and prevent them from making duplicate issues.

Now I realize no one said anything probably because everyone added --format xrgb to their config and didn't bother changing it back, so it still worked.

I see, that might be the case. It is the nature of our community to not expect things to work out of the box. In a way, It is actually a good culture, for it fosters users that are not deterred by workarounds and creative solutions. But in some cases, such culture made the people who work on the codes unable to see the problems, as it grew in complexities down the line.

Interesting. Thanks for that. I really do think this is like, a Mesa bug at this point, but I could be wrong. Because it only fails in certain hardware or configurations. For example, do you by any chance have an integrated display (like in a notebook)?

EDIT: the fact that the compositor crashes further corroborates my hypothesis this is a full-blown mesa bug, now that I think about it.

Yep, on a 5 years old Ideapad 330-15IGM w/ Intel Celeron N4000 and Intel UHD 600 iGPU. I also run mesa 1:24.0.6-2 with Artix Linux 6.8.9. If there are any further stacktrace or system information that you need, I am more than willing to provide you with that.

Cheers

[ENDERZOMBI102]

also having this issue, but on an external monitor; the image is warped, gray-scaled, and is covered in what looks to be scan-lines.

system is running latest Arch (6.9.3-zen1-1-zen) and swww 0.9.5-1 from the AUR, the ext. monitor is 1366x768 while the integrated is 1920x1080.

Seems like running the daemon with --format xrgb fixes it.

Screenshot of the ext. monitor:

[RiedleroD]

I did some debugging on this in sway since some updates randomly triggered this bug for my laptop display today.

It seems to only happen with bgr format (not xbgr nor xrgb) and only at certain scaling values.

Scaling values that work:

• 2
• 1.5
• 1.67
• 1.76

Scaling values that trigger this bug:

• 1.75
• 1.74
• 1.66

Also to note is that hot-reloading the scaling in sway and sending a new image to the daemon refreshes whatever causes the bug, meaning you can have a neat way to test it happening.

Another thing I cought is that at the offending scaling values, my waybar overlay (which is at the bottom) is offset by 1 pixel, and there's 1 line of colored background below it. It's not colored correctly, but it is colored.

So whatever this is seems to be a bug that goes deeper than just swww, but might be triggered by something swww does. I haven't managed to find any other visual bugs so far. I did have some crashes with origin in radeonsi and glibc though. Nothing relevant in dmesg nor journalctl, regardless. My girlfriend suggested it might be related to fractional math being prone to precision problems.

Less important but during my testing I have ruled out the following potential causes: waybar, adaptive sync, subpixel rendering, the file format sent to swww (at least jpg, png and animated webp behave the same), and any non-default user configs outside of sway I set (tested using a fresh user).

Also to note: I tried using swww-git (AUR) for a bit and that one just refused to start 🤷🏻 idunno. I have my workaround and I'm tired, so…

[LGFae]

My girlfriend suggested it might be related to fractional math being prone to precision problems.

I partially agree with her. But I also think that:

So whatever this is seems to be a bug that goes deeper than just swww, but might be triggered by something swww does

If you can reliably trigger the bug, I wonder if there's a way of checking Mesa's log or something. I would really like to know whether this is a Mesa problem.

I tried using swww-git (AUR)

The git version is currently broken (see #337). We will try fixing it with #335, but it may take a little bit.

[cplir-c]

seems to happen every time I launch swww-daemon with a cached image or use swww img on my laptop's internal display unless I use --format xrgb or xbgr to launch the daemon

[cplir-c]

Mesa docs https://docs.mesa3d.org/envvars.html say:

MESA_DEBUG

if set, error messages are printed to stderr. For example, if the application generates a GL_INVALID_ENUM error, a corresponding error message indicating where the error occurred, and possibly why, will be printed to stderr. For release builds, MESA_DEBUG defaults to off (no debug output) . MESA_DEBUG accepts the following comma-separated list of named flags, which adds extra behavior to just set MESA_DEBUG to 1:

silent

   turn off debug messages. Only useful for debug builds.

flush

   flush after each drawing command

incomplete_tex

   extra debug messages when a texture is incomplete

incomplete_fbo

   extra debug messages when a FBO is incomplete

context

   create a debug context (see GLX_CONTEXT_DEBUG_BIT_ARB) and print error and performance messages to stderr (or MESA_LOG_FILE).

...

MESA_LOG_FILE

   specifies a file name for logging all errors, warnings, etc., rather than stderr

[RiedleroD]

interestingly, I can't reproduce this anymore. I'm running swww 0.9.5-2 now. I've removed my workaround and will report back if anything changes.

[cplir-c]

I'm running 0.9.5 on voidlinux

[LGFae]

Ok, so @RiedleroD can not reproduce this anymore and PR #439 should have fixed our long-standing scaling issues. I will be closing this for now. Anyone can feel free to reopen it if this becomes a problem again.