search

LGFae / swww

A Solution to your Wayland Wallpaper Woes
GNU General Public License v3.0
2.34k stars 70 forks source link

issues with swww v0.9.2 about resize "fit" option #279

Closed random2907 closed 6 months ago

random2907 commented 6 months ago

v0.9.1

image

v0.9.2

image

LGFae commented 6 months ago

I need more info. What's the monitor's resolution and the image's size?

random2907 commented 6 months ago

I need more info. What's the monitor's resolution and the image's size?

PNG image data, 1920 x 1080, 8-bit/color RGBA, non-interlaced

➜ ~ swww query eDP-1: 1280x720, scale: 2, currently displaying: image: /home/ranjeet/.wallpapers/wallhaven-5dmxg8.png ➜ ~ hyprctl monitors Monitor eDP-1 (ID 0): 1920x1080@60.00300 at 0x0 description: BOE 0x09AE make: BOE model: 0x09AE serial: active workspace: 2 (2) special workspace: 0 () reserved: 0 40 0 0 scale: 1.50 transform: 0 focused: yes dpmsStatus: 1 vrr: 0 activelyTearing: false currentFormat: XRGB8888 availableModes: 1920x1080@60.00Hz

LGFae commented 6 months ago

This is a scaling problem. swww-daemon is trying to render that image as if the monitor were 2560x1440.

LGFae commented 6 months ago

Since this could affect a lot of people, I decided to do a small release immediately. Thanks for the report!

random2907 commented 6 months ago

Since this could affect a lot of people, I decided to do a small release immediately. Thanks for the report!

for me its not fixed it now not scale no resize option is doing anything its like not scale its fixes when i set my scaling to 1.

image

LGFae commented 6 months ago

for me its not fixed it now not scale no resize option is doing anything its like not scale its fixes when i set my scaling to 1

I'm sorry, I cannot fully understand this sentence. Have you tried the latest version, 0.9.3, with --no-resize option? Is that it?

random2907 commented 6 months ago

for me its not fixed it now not scale no resize option is doing anything its like not scale its fixes when i set my scaling to 1

I'm sorry, I cannot fully understand this sentence. Have you tried the latest version, 0.9.3, with --no-resize option? Is that it?

yes i am using v0.9.3

i mean that its now not even resizing/scaling properly. this is the swww query now. eDP-1: 960x540, scale: 2,

LGFae commented 6 months ago

Hmm... this should be consistent with the previous behavior though. Well, in any case, we are reopening this.

EDIT: as a workaround, you can try resizing your image before sending it through swww.

Akira-uestc commented 6 months ago

swww v0.9.3 WM:hyprland ❯ swww query
eDP-1: 960x540, scale: 2, currently displaying: image: /home/akira/Pictures/pixel/IMG_20231031_172210_589.png ❯ hyprctl monitors
Monitor eDP-1 (ID 0): 1920x1080@60.00000 at 0x0 description: BOE 0x0936 make: BOE model: 0x0936 serial: active workspace: 1 (1) special workspace: 0 () reserved: 0 45 0 0 scale: 1.25 transform: 0 focused: yes dpmsStatus: 1 vrr: 0 activelyTearing: false currentFormat: XRGB8888 availableModes: 1920x1080@60.00Hz 1920x1080@48.00Hz

When not using integer scale, swww cannot tile to full screen 18323324AB0EFFFB28BEB7C77924E5D4

hdm9527 commented 6 months ago

After upgrade swww to v0.9.3 encountered the same problem. Swww v0.9.2 scaling is correct. image

LGFae commented 6 months ago

Wait, @Akira-uestc, @hdm9527, is that happening with the default settings? As in, you just call swww img <picture> and that's what happens? Or are you calling it with --no-resize?

EDIT: ah sorry. I realize now this only happens for non-integer scales. This will be fixed once I implement fractional scaling, which is next on the list. Apologies for the inconvenience; consider this a temporary setback. As a workaround for now, you can try rescaling the image before sending it through swww.

LelouBil commented 6 months ago

For me it happens even with --no-resize and the image being the correct size

swww query
eDP-1: 1280x800, scale: 2, currently displaying: color: 000000
hyprctl monitors
Monitor eDP-1 (ID 0):
    2560x1600@165.00000 at 0x0
    description: 
    make: 
    model: 
    serial: 
    active workspace: 1 (1)
    special workspace: 0 ()
    reserved: 0 48 0 0
    scale: 1.60
    transform: 0
    focused: yes
    dpmsStatus: 1
    vrr: 0
    activelyTearing: false
    disabled: false
    currentFormat: XRGB8888
    availableModes: 2560x1600@165.00Hz 2560x1600@60.00Hz
file .config/hypr/wallpaper.png
.config/hypr/wallpaper.png: PNG image data, 2560 x 1600, 8-bit/color RGBA, non-interlaced

Running sww clear-cache && swww img .config/hypr/wallpaper.png --no-resize gives me the same output as the people commenting above.

zzucch commented 6 months ago

Same here, --no-resize does not help.

swww 0.9.3, hyprland 0.38.1

image

$ swww query
eDP-1: 960x540, scale: 2, currently displaying: image: /home/zcchr/walls/black.jpg
$ hyprctl monitors
Monitor eDP-1 (ID 0):
    1920x1080@60.00000 at 0x0
    description: BOE 0x092E
    make: BOE
    model: 0x092E
    serial: 
    active workspace: 4 (4)
    special workspace: 0 ()
    reserved: 0 28 0 0
    scale: 1.25
    transform: 0
    focused: yes
    dpmsStatus: 1
    vrr: 0
    activelyTearing: false
    currentFormat: XRGB8888
    availableModes: 1920x1080@60.00Hz 1920x1080@48.00Hz 1680x1050@60.00Hz 1280x1024@60.00Hz 1440x900@60.00Hz 1280x800@60.00Hz 1280x720@60.00Hz 1024x768@60.00Hz 800x600@60.00Hz 640x480@60.00Hz
$ file ~/walls/black.jpg 
/home/zcchr/walls/black.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 99", baseline, precision 8, 1920x1080, components 3
itsmenewbie03 commented 6 months ago

Same here, --no-resize does not help.

swww 0.9.3, hyprland 0.38.1

image

$ swww query
eDP-1: 960x540, scale: 2, currently displaying: image: /home/zcchr/walls/black.jpg
$ hyprctl monitors
Monitor eDP-1 (ID 0):
  1920x1080@60.00000 at 0x0
  description: BOE 0x092E
  make: BOE
  model: 0x092E
  serial: 
  active workspace: 4 (4)
  special workspace: 0 ()
  reserved: 0 28 0 0
  scale: 1.25
  transform: 0
  focused: yes
  dpmsStatus: 1
  vrr: 0
  activelyTearing: false
  currentFormat: XRGB8888
  availableModes: 1920x1080@60.00Hz 1920x1080@48.00Hz 1680x1050@60.00Hz 1280x1024@60.00Hz 1440x900@60.00Hz 1280x800@60.00Hz 1280x720@60.00Hz 1024x768@60.00Hz 800x600@60.00Hz 640x480@60.00Hz
$ file ~/walls/black.jpg 
/home/zcchr/walls/black.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 99", baseline, precision 8, 1920x1080, components 3

experiencing the same

heltechael commented 6 months ago

Same here, --no-resize does not help. swww 0.9.3, hyprland 0.38.1 image

$ swww query
eDP-1: 960x540, scale: 2, currently displaying: image: /home/zcchr/walls/black.jpg
$ hyprctl monitors
Monitor eDP-1 (ID 0):
    1920x1080@60.00000 at 0x0
    description: BOE 0x092E
    make: BOE
    model: 0x092E
    serial: 
    active workspace: 4 (4)
    special workspace: 0 ()
    reserved: 0 28 0 0
    scale: 1.25
    transform: 0
    focused: yes
    dpmsStatus: 1
    vrr: 0
    activelyTearing: false
    currentFormat: XRGB8888
    availableModes: 1920x1080@60.00Hz 1920x1080@48.00Hz 1680x1050@60.00Hz 1280x1024@60.00Hz 1440x900@60.00Hz 1280x800@60.00Hz 1280x720@60.00Hz 1024x768@60.00Hz 800x600@60.00Hz 640x480@60.00Hz
$ file ~/walls/black.jpg 
/home/zcchr/walls/black.jpg: JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 99", baseline, precision 8, 1920x1080, components 3

experiencing the same

Also experiencing this when using Hyprland monitor config: monitor=,1920x1080@60,auto,1.25. Resizing the image by multiplying the fractional scale before sending it through swww did not work for me either. I tried:

swww: 0.9.3 Hyprland: 0.38.1

LGFae commented 6 months ago

Oh, right, sorry. This is a fundamental problem of the surface size we are using. It's just going to break every time. There is no workaround actually.

legendboyAni commented 6 months ago

Oh, right, sorry. This is a fundamental problem of the surface size we are using. It's just going to break every time. There is no workaround actually.

why no downgrade option you should at least keep 5 to 10 version

LGFae commented 6 months ago

why no downgrade option you should at least keep 5 to 10 version

Downgrade isn't controlled by me. All the previous versions are still there. Downgrading must be supported either by your package manager, or you must do it yourself if you compiled manually.

azurstar commented 6 months ago

why no downgrade option you should at least keep 5 to 10 version

you can downgrage to 0.8.2 by AUR.

git clone https://aur.archlinux.org/swww.git && cd swww
git reset --hard f5971656d37d7ded2e803f9655685c416ca6b71e
paru -Ui
LGFae commented 6 months ago

PR #282 should fix this. I've tested under sway over here in my setup. Can anyone confirm me it works? (or doesn't)

zzucch commented 6 months ago

PR #282 should fix this. I've tested under sway over here in my setup. Can anyone confirm me it works? (or doesn't)

It resolved the issue for me, thanks.

heltechael commented 6 months ago

I can confirm that it works for me, @LGFae! Thank you for your excellent work.