swww icon indicating copy to clipboard operation
swww copied to clipboard

Swww not stretching vertical montitor

Open xsghetti opened this issue 1 year ago • 37 comments

It will set the background, but does not respect the monitor properties

image

xsghetti avatar Apr 11 '24 04:04 xsghetti

Are you using monitors transforms, by any chance? If you are, we currently just ignore transforms.

LGFae avatar Apr 11 '24 14:04 LGFae

Yes my vertical is using transform

xsghetti avatar Apr 11 '24 14:04 xsghetti

Will there be a fix for this coming?

xsghetti avatar Apr 11 '24 15:04 xsghetti

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.

LGFae avatar Apr 11 '24 15:04 LGFae

Thank you for the effort, I will wait until this issue is fixed to come back to swww

xsghetti avatar Apr 11 '24 16:04 xsghetti

any word on this?

xsghetti avatar Apr 15 '24 02:04 xsghetti

Having the same issue after upgrading to 0.9.3. I've reverted to 0.9.1 for time being which fixes the problem.

endeavour avatar Apr 16 '24 10:04 endeavour

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:

LGFae avatar Apr 17 '24 00:04 LGFae

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

fit

When using --resize crop

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.

foo92

I have been able to confirm that the bug does not occur when using version v0.9.1

foo91

HakierGrzonzo avatar Apr 19 '24 21:04 HakierGrzonzo

For me it looks fine without any resizing on my 21:9 display despite the image being 16:9 image

But on my second monitor that is portrait mode and 9:16 image

RandomLegend avatar Apr 20 '24 08:04 RandomLegend

Similar problem here as @HakierGrzonzo , and it works normally for version v0.9.1.

clsty avatar Apr 20 '24 10:04 clsty

@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.

Jax-Tsai-zero avatar Apr 20 '24 17:04 Jax-Tsai-zero

@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.

LGFae avatar Apr 20 '24 17:04 LGFae

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!

xsghetti avatar Apr 20 '24 17:04 xsghetti

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 avatar Apr 20 '24 17:04 LGFae

@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.

Jax-Tsai-zero avatar Apr 20 '24 18:04 Jax-Tsai-zero

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 avatar Apr 20 '24 19:04 LGFae

@LGFae will confirm tomorrow

HakierGrzonzo avatar Apr 20 '24 20:04 HakierGrzonzo

@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.

clsty avatar Apr 20 '24 23:04 clsty

Thanks. Guess we'll have to wait a bit until I have access to a similar setup to fix this.

LGFae avatar Apr 20 '24 23:04 LGFae

@LGFae This is my setup on commit 70e63d74d541b97c0a813cbd5518e541e8c317bb

fix-vertical-monitor

HakierGrzonzo avatar Apr 21 '24 12:04 HakierGrzonzo

@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?

Jax-Tsai-zero avatar Apr 22 '24 09:04 Jax-Tsai-zero

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.

Jax-Tsai-zero avatar Apr 22 '24 09:04 Jax-Tsai-zero

Ohhhh! I finally found that set_vertical is called before set_dimensions. @LGFae Do you know how could we fix this, bro?

Jax-Tsai-zero avatar Apr 22 '24 09:04 Jax-Tsai-zero

I've pull a PR #292 to fix that, it works fine on my machine.

Jax-Tsai-zero avatar Apr 25 '24 11:04 Jax-Tsai-zero

Merged #292. This should be fixed now.

LGFae avatar Apr 25 '24 12:04 LGFae

I will be closing this since #292 should have fixed it. Anyone can feel free to reopen it otherwise.

LGFae avatar Apr 27 '24 13:04 LGFae

@LGFae I think i'm still suffering from this issue:

240804_22h00m23s_screenshot

both --resize crop and --resize fit have the same result. Is there some config param i'm missing maybe?

mjkl-gh avatar Aug 04 '24 20:08 mjkl-gh

I'm encountering this issue again

xsghetti avatar Nov 21 '24 17:11 xsghetti

I'm encountering this issue again

Same here

CharlyMH avatar Dec 07 '24 13:12 CharlyMH