settimed fails to set transition wallapaper
yegorius opened this issue · 11 comments
settimed correctly sets wallpaper during the launch, but crashes in the next 20 minutes or so:
Crossfading between images.
Window: 20m
Cooldown: 2m
Loop wait: 5s
Transition type: overlay
From filename /usr/share/backgrounds/gnome/mojave/mojave_dynamic-1000.jpg
To filename /usr/share/backgrounds/gnome/mojave/mojave_dynamic-1100.jpg
Crossfading between images.
Setting /tmp/gnometimed_crossfade.png.
Using the Feh backend.
feh --bg-scale /tmp/gnometimed_crossfade.png
Setting /tmp/gnometimed_crossfade.png.
Using the Feh backend.
feh --bg-scale /tmp/gnometimed_crossfade.png
failed: feh --bg-scale /tmp/gnometimed_crossfade.png failed to run
Using the X11 backend.
convert /tmp/gnometimed_crossfade.png /tmp/_setwallpaper.xbm
failed: feh --bg-scale /tmp/gnometimed_crossfade.png failed to run
Using the X11 backend.
convert /tmp/gnometimed_crossfade.png /tmp/_setwallpaper.xbm
Setting /tmp/gnometimed_crossfade.png.
Using the Feh backend.
feh --bg-scale /tmp/gnometimed_crossfade.png
failed: feh --bg-scale /tmp/gnometimed_crossfade.png failed to run
Using the X11 backend.
convert /tmp/gnometimed_crossfade.png /tmp/_setwallpaper.xbm
malloc(): unsorted double linked list corrupted
SIGABRT: abort
...
If I then try to run feh on /tmp/gnometimed_crossfade.png :
feh --bg-scale /tmp/gnometimed_crossfade.png
libpng error: bad adaptive filter value
feh WARNING: /tmp/gnometimed_crossfade.png - No Imlib2 loader for that file format
feh ERROR: Unable to load image /tmp/gnometimed_crossfade.png
OS: Arch Linux
WM: i3
Thanks for reporting! I will look into this. The X11 backend is the most fragile of all the available backend. It was surprising to me that the feh backend failed with the cross fade image. I will fix this.
I added functionality to x11.go and xwallpaper.h for setting XPM images as the background image, for X11, instead of using feh or the XBM format. This could be improved further by not writing to a temporary file and setting the image data directly through the X11-related C-functions.
However, images with too many colors may still be an issue.
I also need to test this new functionality a bit more.
I created the palgen package and made some changes to the xpm. It can now reduce the number of colors when converting images to .xpm. It could probably be both faster and more robust, but it should remove the issue of images having too many colors when setting .xpm images as wallpapers.
Please test the latest master of wallutils and see if the issue has now been resolved.
I'm also planning to do some more testing on various window managers for X.
I just tested with i3, and it works best with the feh method. I'm also on Arch Linux.
Since your installation says:
feh WARNING: /tmp/gnometimed_crossfade.png - No Imlib2 loader for that file format
feh ERROR: Unable to load image /tmp/gnometimed_crossfade.png
Perhaps your installation of imlib2 has been compiled without support for PNG files?
Could you please try reinstalling feh and/or imlib2, or possibly install any missing packages that could be related?
After looking into this error: libpng error: bad adaptive filter value, I think there may be something wrong with the png image itself, possibly a concurrency issue, if the writing of the png image was aborted somehow.
I will try to reproduce the error by running the same command as you did.
I have the latest version of feh and imlib2 from Arch and imlib2 is compiled with png support. Anyway, here is the fresh log output
Thanks for the log output! I looked into this, and there is something wrong with the function that performs the cross-fade between two images, in relation to concurrency, resulting in half-written images. I will fix this.
I have made several changes related to the cross-fade functionality.
- Now using bild for the crossfade (blend).
- Using a mutex when writing the temporary image, to make sure it can write it in peace.
Please test the latest master and see if it fixes this issue. Thanks!
Now there are other issues. The Mojave wallpaper events are not correct. I'll have to look into this as well. But this issue might be fixed.