Swww not stretching vertical montitor
It will set the background, but does not respect the monitor properties
Are you using monitors transforms, by any chance? If you are, we currently just ignore transforms.
Yes my vertical is using transform
Will there be a fix for this coming?
Can you check if PR #276 fixes the issue for you?
Will there be a fix for this coming?
If PR #276 does not fix it, it might take a little bit.
EDIT: actually, looking at it now, I am pretty sure that's not enough to fix the issue. So yeah, I want to fix it, but don't know how long it will take.
Thank you for the effort, I will wait until this issue is fixed to come back to swww
any word on this?
Having the same issue after upgrading to 0.9.3. I've reverted to 0.9.1 for time being which fixes the problem.
Sorry, #279 took all of my time since it was quite urgent. I am going to get a little busy in the following weeks, so I can't really promise anything :sweat:
I have encountered the same issue but with a twist.
I have one vertical monitor, one ultrawide and one scaled.
The wallpaper is correctly resized for the ultrawide one, which happens to be the first monitor returned by wlr-randr.
Attaching screenshots for reference (versions v0.9.3 and v0.9.4 behave in the same way):
When using --resize fit
When using --resize crop
I have also tried going back in time, this is the result when I am running version v0.9.2, here the scaled output is working correctly.
I have been able to confirm that the bug does not occur when using version v0.9.1
For me it looks fine without any resizing on my 21:9 display despite the image being 16:9
But on my second monitor that is portrait mode and 9:16
Similar problem here as @HakierGrzonzo , and it works normally for version v0.9.1.
@LGFae Same bug on my machine. After reading the source code, I found that the dimension of wallpaper is set by wallpaper.set_dimension(width, height) at line 534 of main.rs of daemon, and the height and width comes from wl_output::Event::Mode {flag, width}, but this enum seems not contain the monitor transform config variable of wayland. Maybe That is the reason why swww does not work properly on vertical monitors.(AI said that this value can get from wl_output::WlOutput.wl_output.Transform, I'm not sure it's right) I'm not a rust guy myself btw, hope my opinion will help you to fix this and not be a misleading.
@AhJi26. Yeah, I actually also think that's how we are supposed to solve this. Though it won't solve @HakierGrzonzo's problem, since one of his outputs without transforms is also scaling incorrectly.
I really wish I knew how to code because I would love to help with this issue, but I'm merely just a consumer :( Hope this issue being open is helping to spin the gears on this a little more. I ended up just bringing my other monitor back to normal because I just can't imagine not using SWWW. keep up the good work!
So, like I said. Pretty sure #291 fixes the basic issue of scaling on vertical monitors. But it might not solve the problem with multiple monitors that has also been reported here.
@LGFae Hmm,,, You're right. This only fix half of his problem. In my opinion, he has that problem because he use different scaling factor simultaneously on several monitors. And at line 536 of main.rs of daemon, Scale::Whole() provide the scaling factor. My guess is that this api does not provide scaling factor matching each monitor but a whole scaling factor, so all monitor actually share the same scaling factor.
That's not entirely correct. Note that just a little above that we are looping through the wallpapers to find the one this event corresponds to. So yes, the scaling factor is entirely independent between monitors.
However, reading this gave me a different idea. It seems the way I was identifying which output to apply the scaling to might have been wrong. The documentation states that proxy.id().protocol_id() does not remain the same. So that could have been the problem. @HakierGrzonzo could you confirm me if you still have the issue on your multiple monitor setup with #291 applied?
@LGFae will confirm tomorrow
@HakierGrzonzo could you confirm me if you still have the issue on your multiple monitor setup with https://github.com/LGFae/swww/pull/291 applied?
I'm using multiple monitors with different scaling and one of them vertical.
I downloaded AUR package swww-git and modified its PKGBUILD by editing source=("$pkgname::git+$url.git")
to source=("$pkgname::git+$url.git#branch=fix-vertical-monitor"), and then build&install by running makepkg -si .
Then swww kill ; swww-daemon, and on another terminal run swww img --resize crop -t none -o <the vertical monitor> <the image path>.
Unfortunately it's just the same as v0.9.4.
Thanks. Guess we'll have to wait a bit until I have access to a similar setup to fix this.
@LGFae This is my setup on commit 70e63d74d541b97c0a813cbd5518e541e8c317bb
@LGFae bro I just clone the "fix-vertical-monitor" branch and build it, but it still not work properly on vertical monitor for some reason.and the daemon log said
08:57:02 [INFO] (main) Selected wl_shm format: Bgr888
08:57:02 [INFO] (main) Initialization succeeded! Starting main loop...
08:57:02 [WARN] (main) Received transform. We currently ignore those
08:57:02 [WARN] (main) Received transform. We currently ignore those
08:57:02 [INFO] (transition) BumpPool with: 1 buffers. Size: 6075Kb
08:57:02 [INFO] (transition) BumpPool with: 1 buffers. Size: 6075Kb
08:57:02 [INFO] (transition) BumpPool with: 2 buffers. Size: 12150Kb
08:57:02 [INFO] (transition) BumpPool with: 2 buffers. Size: 12150Kb
I add debug info manully and find it runs into set_vertical function properly, but the wallpaper still display as horizontal. what could be wrong?
I add debug!("dim = {:?}x{:?}", lock.width, lock.height); at end of set_vertical, but it turns out [DEBUG] (main) swww_daemon::wallpaper: dim = 4x4.
Ohhhh! I finally found that set_vertical is called before set_dimensions. @LGFae Do you know how could we fix this, bro?
I've pull a PR #292 to fix that, it works fine on my machine.
Merged #292. This should be fixed now.
I will be closing this since #292 should have fixed it. Anyone can feel free to reopen it otherwise.
@LGFae I think i'm still suffering from this issue:
both --resize crop and --resize fit have the same result. Is there some config param i'm missing maybe?
I'm encountering this issue again
I'm encountering this issue again
Same here