Sway: 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.