Add a way to configure overscan

[unmellow]

if their is a way to do this the docs do not explain it in a way i can understand

my tv says that overscan is off and won't even let me change the setting so i need a way to manually set the edge borders

[ascent12]

Just to confirm, you issue is with overscan, where you either have a black border around the outside, or the edges are cut off?

[unmellow]

my issue is overscan yes i can't disable it on my monitor

edit: i get cut off or black borders with cut off i never see the whole screen unless i do 1366x768 then everything looks fine except for green lines on the edges of my screen although this happens on gnome and my tty too

[ascent12]

Ugh, I really hate overscan. One of those annoying analog hacks that should've completely died when things went digital, but didn't. I was honestly hoping this was something that could've been ignored, but I know it's still a real issue out there, and the display server is the one that is supposed to be the one to do something about it.

There is a DRM property for this, so support needs to be added to wlroots' DRM backend. I don't actually know what the numbers really mean. For me on amdgpu, it's

├───"underscan": enum {off, on, auto} = off
├───"underscan hborder": range [0, 128] = 0
├───"underscan vborder": range [0, 128] = 0

But this isn't in the standard set of properties, and goes into driver-specific territory. It seems like several different drivers came up with their own incompatible solutions to this. I'm not sure what I want to do about this.

[unmellow]

it's weird for me because i didn't have this issue on my old rig with an nvidia 760 then i upgraded everything except my monitor and got an amd 550 and now this is an issue i assume my monitor doesn't like new graphics cards but why tf does my xbox work fine?

[nab-os]

I would love this feature too, for now i just use 4 blank waybars

[emersion]

Note, the underscan property seems to be supported by both amdgpu and nouveau: https://drmdb.emersion.fr/properties/3233857728/underscan

[emersion]

Hmm, seems like vc4 has some margin properties instead: https://drmdb.emersion.fr/properties/3233857728/right%20margin

Might be worth asking the DRM devs what's up with these properties. Drivers aren't supposed to be adding driver-specific props anymore.

[r-c-f]

@emersion The margin properties are supposed to be the standard, but prior to https://github.com/torvalds/linux/commit/6c4f52dca36f5e3e2354c30591d38e92f4657ed9 in 2018 they were intended for SDTV connectors only. i915 continues to restrict margin to SDTV outputs. vc4 didn't have the functionality at all until after this point, so it got margin support for HDMI. Everyone else had been relying on underscan for almost a decade in some cases, so it's stuck around.

[jnpkrn]

Would any sort of driver-agnostic workaround be thinkable for the case of edges being cut off? Something like:

output 'Troubling monitor' resolution 1920x1080@60Hz \
  blindfold_padding 30 50 30 50 ...

which would automatically shrink the usable area by 60 pixels horizontally and by 100 pixels vertically, from each border to the center respectively. Here, rather symmetrically (for which a shortcut aking to CSS could be devised) but not necessarily, filling these padded edges just with some color and preventing the cursor to hop into this territory (in case of multihead output, jumping over right to the following one when applicable).

It can be partially approximated with default_border, but it affects also the output that is fully sane, sadly.

This monitor in particular can be fixed with a different "Size" in its menu, but all other modes would only enforce the black borders along the wider side, which is the exact opposite and non-workaroundable case, and hence I'd like to avoid that.

Btw. on Windows, using Intel's configuration tool, I was able to resolve the same problem by using its scaling option (separate for horizontal and vertical direction, which is apparently needed in my case, this is, sure enough, a driver-specific thing).

[jnpkrn]

Discovered there is gaps property of the workspace already, with all the per-edge separate configurability.

So I'd likely be able to have something sufficient if I configured/scripted workspace-to-output assignment and from here, changed the gaps property individually.

Still, it'd be more convenient to have automatic inheritance from output-level override. Also because of output entry dealing with immutable standard display orientation (you don't change the resolution definition each time you change rotation), whereas gaps property of the workspace already puts per-output logical orientation into account -- if I change the orientation of the display, these workaround gaps shall follow that automatically, propagating to workspace interpretation correctly. Otherwise I'd need to modify gaps accordingly each time I rotated my display :-)

Also note that the cursor-skips-the-gap behaviour is not there with gaps, however, given the (usually) minimal size of such gaps, this is solely nice-to-have.

EDIT: and, of course, problem with gaps (or default_border) is that it doesn't apply when anything is switched to fullscreen. Also, would this have to be implemented in i3 to be even consired? I suppose the very root cause could be addressed with some driver specific xrandr incantations, but Wayland is another matter.

[wolterhv]

Is this something that should be solved in sway or rather in wlroots?

[AftDawn]

Is there a fix for overscanning displays in Wayland?

[axyiee]

Any updates on this?

[Kabouik]

I would love this feature too, for now i just use 4 blank waybars

Could you share your Waybar configuration to achieve this? It's hacky but could be useful.

As for gaps @jnpkrn, do you know of any way to use them when there is a single window in the workspace? I have keybindings defined in Sway to increase or decrease gaps, but they only show when multiple windows are tiled. Of course, this would not solve overscan for fullscreen windows, and the bar would also not be inside the gapped area, but this could also be an acceptable workaround.

My issue is not really overscan, but AR glasses like Xreal, where the outermost pixels can be hard to read when there is text for some users, myself included. Underscanning would help using them as portable monitor for work.