Comments
subsentient
I'd remember that there are other WMs with basic support for wallpapers, like Fluxbox, Openbox, IceWM, JWM, etc, that have varying degrees of support for wallpapers. I'm confident these can't use .webp images. Some of those window managers are well-loved abandonware or neglectware that keep being recompiled for several Fedora releases because people still want to use them, and they still work. Just don't expect them to add support for .webp anytime soon.
Everything supports PNG, Fedora has been using it forever, and whatever meager space savings you get almost certainly aren't worth the compatibility issues for all these window managers.
I also feel that the decision to switch to WEBP brings questionable if any technical benefits. If it's compressed in lossy WEBP, JPEG would have done a better job: https://en.wikipedia.org/wiki/WebP#Criticism If it's compressed losslessly, it can't possibly save enough space to be worth the compatibility nightmare.
@nixuser I strongly agree. I've been seeing increasingly questionable decisions from Fedora lately, making me contemplate switching distros for the first time in a decade. As all my hardware runs Fedora, that would be quite an undertaking, which is probably why I haven't. For example, I used the ARMv7 port of Fedora on multiple little SBCs. There was recently talk of requiring AVX2 for the x86_64 distro, even though a cheap laptop I bought at walmart a couple months back doesn't even support AVX. Reminds me of Windows 11's debacle. Why is Fedora trying to stoop to the level of Windows and macOS lately? Contamination by corporations?
lightdm can't use WEBP images. Black wallpaper on login screen now. In addition, as another has reported, Xfce does not support WEBP either, so these images are totally unusable for Xfce and I suspect several other window managers in the Fedora repos.
What was wrong with PNG? Everything supports it. I get the desire to be trendy and use the latest fad technology, but this is a good example of when not to.
I will report that my GPD Pocket 2 with the Celeron 3965Y is stabilized by switching the IO Scheduler to mq-deadline, so BFQ bugs were, at least, the cause of the issues on my system. So definitely give that a try if you haven't.
In the meantime you can just echo mq-deadline | tee /sys/block/*/queue/scheduler to switch to a (in many cases faster anyways) different IO scheduler.
Yeah, but the machine having the issue is usually running that custom kernel (needs the features), so I'm going to see if that patch and that patch alone, when applied to a vanilla kernel, will fix the issue. Just started the COPR job for the rebuild. I'll let you know how it pans out.
What commit is reverted here? What's the changeset? I also maintain a custom kernel I use on several systems, I'd like to add the patch there too.
From what I can tell -- these issues occur on systems that do not support AVX/AVX2, like my Celeron 3965Y. That is probably relevant.
Causes hard lockups when a KVM guest is running on my GPD Pocket 2 with a Celeron 3965Y CPU and 8GB RAM. Runs fine for a random amount of time (less than an hour) and then the host OS hard locks up requiring me to hold the power button down. I can't get anything from dmesg and NMI watchdog isn't giving me anything before it hangs. Last tested kernel that functions correctly is 5.14.4.
@mtasaka Here you go, as requested. https://bugzilla.redhat.com/show_bug.cgi?id=1959761
@mtasaka I will post the issue here in any case. On some machines, after several attempts with the correct password, it eventually lets me in. The number of required attempts is unpredictable. On others, the only option is logging in via TTY or ssh and killing xscreensaver.
@mtasaka Are you sure you want a bug report for a package only in testing? I can create one if you like, but seems a bit odd, at least to me.
On every system that uses this version of xscreensaver, I am frequently unable to unlock the screen at all, and must jump to a TTY to kill the xscreensaver process.
Downgrading to the version in the stable "fedora" repo fixes the issue instantly. Whatever was changed, it's not an improvement.
I'll look into filing a bug report, though I'd hope it's the kind of obvious issue they'd find immediately. I'd pull this for all releases of Fedora.
Can you unpush this one as well @nonamedotc? The graphical distortions happen on both fc32 and fc33, and I would assume rawhide as well.
Can someone integrate the patch for aarch64 yet and spin off a new build? https://universe2.us/collector/build-aarch64.patch
@luya Noticed the conspicuous lack of widescreen versions, but if Fedora didn't make any for this release, then it seems good.