Uncommon resolution - bottom row of pixels not used for windows

[JulianFP]

Hyprland Version

v0.30.0

Bug or Regression?

Bug

Description

On my laptops internal screen Hyprland doesn't use the bottom row of pixels to display windows. Instead only the wallpaper is shown there. If your wallpaper is black this doesn't really hurt (except that you loose a row of pixels), but if there is something colorful on your wallpaper (like our beloved hypr-chan) it gets annoying really fast, especially for fullscreen applications (e.g. when watching a movie, playing a game, etc.)

I am using Hyprland on a Framework Laptop 13 whose internal display has a quite uncommon resolution:

> hyprctl monitors
Monitor eDP-1 (ID 0):
    2256x1504@59.99900 at 0x0
    description: BOE 0x095F (eDP-1)
    make: BOE
    model: 0x095F
    serial:
    active workspace: 2 (2)
    special workspace: 0 ()
    reserved: 0 30 0 0
    scale: 1.50
    transform: 0
    focused: yes
    dpmsStatus: 1
    vrr: 0

How to reproduce

Use Hyprland on a similar display. Fractional scale doesn't matter (I have tried 1 and 1.5), neither does the type of application. Nothing gets displayed on the bottom row except the desktop wallpaper and the mouse (if I move it to the bottom). This bug isn't new (it exists since at least v0.27.2) and I was able to reproduce it on both Arch and NixOS.

Crash reports, logs, images, videos

I attached some pictures that I took with my smartphone (taking screenshots was not possible since grim doesn't capture those pixels either). As an example I just used alacritty

I took this last image just that you see that this line of pixels is from the hypr-chan background.

[vaxerski]

what layout is that

[JulianFP]

what layout is that

sorry, I forgot to attach my config, here it is. I use the dwindle layout, but I can also reproduce this with the master layout.

hyprland.txt

[vaxerski]

patch.txt try this patch (only dwindle)

[JulianFP]

patch.txt try this patch (only dwindle)

thank you, but unfortunately it didn't help, no difference.

[JulianFP]

I did some more testing with scaling, and I have to correct my previous statement: Scaling makes a difference:

• x0.75 - x1.28: problem does not occur
• x1.29 - x1.99: problem occurs
• x2: problem does not occur
• x2.01 - x3: problem occurs

This behavior is the same with and without the patch. So it seems to be a problem with fractional scaling after all. I could have sworn that I saw this problem with a scaling of x1 as well, but I couldn't reproduce it now. Must have confused something...

[vaxerski]

my guess is fractional pixels, somewhere, as usual with those.

[FakeMichau]

It happens to me on a 3440x1440 screen (no scaling) but not only on the bottom, sometimes even between windows. Personally I've been using gaps_in = -1 as a workaround.

The patch sent in here somewhat fixes the issue for me. Wallpaper isn't visible but border width is uneven - sometimes it's one pixel, sometimes two.

[xz-dev]

I use waylock as my screenlocker, same problem when I start waylock. But it not happened every time, and the problem wont happening at Monitor DP-3, only at eDP-1, if I use command hyprctl keyword monitor "eDP-1, disable" && hyprctl keyword monitor "eDP-1, preferred, 2560x0, auto, bitdepth, 10" will fix it.

❯ hyprctl monitors Monitor DP-3 (ID 1): 3840x2160@60.00000 at 0x0 description: HKC OVERSEAS LIMITED P6 0000000000001 (DP-3 via HDMI) make: HKC OVERSEAS LIMITED model: P6 serial: 0000000000001 active workspace: 1 (1) special workspace: 0 () reserved: 0 30 0 0 scale: 1.50 transform: 0 focused: yes dpmsStatus: 1 vrr: 0

Monitor eDP-1 (ID 0): 2560x1600@60.00100 at 2560x0 description: California Institute of Technology 0x160C (eDP-1) make: California Institute of Technology model: 0x160C serial: active workspace: 2 (2) special workspace: 0 () reserved: 0 30 0 0 scale: 1.50 transform: 0 focused: no dpmsStatus: 1 vrr: 0

[vaxerski]

please test #3524

[imxyy1soope1]

please test #3524

problem still occurs

using 2560x1440 monitor, with x1.33 scaling

x1.0 scaling works without problem

EDIT: in my case, only integer scalings work properly. wallpapers can't use that line of pixels either, tested swaybg and hyprpaper

[FakeMichau]

Is that on master or dwindle? The PR is only suppose to fix dwindle, master is kinda mess in that aspect.

[imxyy1soope1]

Is that on master or dwindle? The PR is only suppose to fix dwindle, master is kinda mess in that aspect.

dwindle

[FakeMichau]

Ok, I can see it. It's so much worse at 1.33. Will try to think of a fix

[vaxerski]

yeah sorry github auto-closed the issue

[FakeMichau]

https://github.com/hyprwm/Hyprland/pull/3524 probably will have to be limited to no scaling for the time being (or just reverted). Beside the issue still being present with fractional scaling, it causes windows to move around a little in unexpected ways when used with fractional scaling.

I propose this patch to revert the change when using fractional scaling. patch.txt

Personally I don't see a good solution to this problem when scaling is involved. The windows can be perfectly aligned but before rendering each window is scaled independently throwing away any previous alignment.

[FakeMichau]

It is still very much an issue, especially with fractional scaling - look at the right side of the video, as well as bottom and between windows. The compression kinda makes it less visible tho. Additionally PR #3524 that is suppose to fix it is causing issues with the top right window moving/resizing when it shouldn't when using scaling, as shown on the video. I also include the config I used for testing, with txt extension. hyprland.txt

https://github.com/hyprwm/Hyprland/assets/49685661/4d61378c-d266-45e1-b0b7-188d93a05e06

[vaxerski]

well, I tried

[vaxerski]

patch.txt can you try this chonker for the gaps issue

[FakeMichau]

You reverted the PR I mentioned but because of that FIRSTSIZE needs to be a float/double, not int. Otherwise the weird window resizing I show in the previous clip will always increase window's size because it efficiently floors the number and gives that bit of extra size to the right window.

And more importantly, the patch works but only if you are using integer scaling. That's progress but fractional scaling like 1.33x still has gaps (that's what the image below shows). 1.5x is mostly fine from what I can tell but there still is a gap on the right and bottom - which was the original issue here

[vaxerski]

that's most likely due to fractional pixels, which cannot exist. I am guessing the problem won't occur if your scale will produce integer logical sizes.

[vaxerski]

with the above commit this looks fixed to me. Lmk

[FakeMichau]

Integer scaling and 1.5x scale seem to don't have any gaps 1.25x and 1.75x still have gaps between windows and on the top and sides 1.33x still has gaps between windows but gaps around the screen can be removed by... adding more threes to the scale - 1.3333x only has gaps between windows but not on the edges.

Maybe unrelated but when going through the code I remember seeing that if you type in 1.33 for scale, it sometimes uses that value but other times 1.(3) is used for some reason. Tho I can't recall where that was.

Overall I'd say it's improved but not resolved.

[dyatelok]

I also had this problem. 1.5 didn't work for me (2560x1440@165.00301 at 0x0 laptop screen) and those annoying pixels almost always were there on the right side of the screen. 1.5111 works for me and makes no gaps. If someone will stumble upon this - try to play with scaling for a bit.

[PartyWumpus]

Just had this problem on my machine (2560x1600), and there was an error added in https://github.com/hyprwm/Hyprland/commit/6b6f3396cfb6cabcf64d21dac773eecbdc5954f0 which tells you exactly what the problem is, and likely would have immediately led me to the fix, but it appears to not show up if scaling is set to auto, which is the default. This is probably not the intended behaviour?

The code even finds the nearest okay scale, so auto could probably just use that, if possible.

Edit, it looks like the code is supposed to do this already https://github.com/hyprwm/Hyprland/commit/46997a764304366d772456c20b1c719960927aa7 but it isn't. I'm on version 0.36.0, which should have this change.

Edit 2: Nevermind, looks like it's just wrong sometimes. Auto gives me 1.6, and if i manually set it to 1.6 there is no error, and if i set it to 1.5 it even suggests moving to 1.600000. (but 1.6 has this issue)

[xz-dev]

Also can be reproduced on KDE, could this be a KDE's issue?

[vaxerski]

can you test with #5748 merged?

[JulianFP]

can you test with #5748 merged?

Just tested it and it actually fixed it for me! I can finally watch anime without distracting pixels at the bottom on my laptop screen, thank you @eriedaberrie @vaxerski