what does setting overscan actually do? Does it change the resolution of the HDMI signal?

[alanbork]

In boot/config.txt you can "disable_overscan=1". But I've found that the amount of overscan (if any) needed depends on the video mode I'm using.

What exactly does overscan do to the video signal? Does it actually change what signal is sent over HDMI (such as transmitting 1280x720,as, say, 1300x740?), or is it just re-rendering every drawing command to an inset rectangle, giving you a smaller effective resolution (1280x720 becomes 1260x700 drawable?) And is there a way to apply it only to one video mode or just to the command line frame buffer and not x11 or opengl?

[jamesh]

The second, the Hdmi signal is unchanged.

[alanbork]

The second, the Hdmi signal is unchanged.

Thanks for confirming that! in that case it ought to be possible to change the over-scan parameters while booted, or on a per-mode basis?

This is what I've done to make all text visible at the command line, which seems to work fine on the pi zero but gives corrupted results on the PI 4:

tvservice -e "cea 2"
sleep .5
fbset 640x480-60 -yres 460
sleep .5
fbset -depth 8 & fbset -depth 16
tvservice -s

There must be a more proper way to do this that doesn't rely on rebooting.

[jamesh]

The second, the Hdmi signal is unchanged.

Thanks for confirming that! in that case it ought to be possible to change the over-scan parameters while booted, or on a per-mode basis?

This is what I've done to make all text visible at the command line, which seems to work fine on the pi zero but gives corrupted results on the PI 4:

tvservice -e "cea 2"
sleep .5
fbset 640x480-60 -yres 460
sleep .5
fbset -depth 8 & fbset -depth 16
tvservice -s

There must be a more proper way to do this that doesn't rely on rebooting.

No, it's not changeable on the fly AFAIK. Certinaly not on legacy grpahics - there might be a way in DRM/KMS as we can change the resolution,, but I don't know what it might be.

[cleverca22]

and in the more hacky terrority, you have https://github.com/ali1234/raspi-teletext/

that doesnt change the size of the display area, but instead the lengths of the front/back porch, to shift the display area upwards into into the VBI area (which overscan hides)

and then by putting the right graphics into that upper part of the screen, the tv would parse it as teletext data

from what ive seen of the drm/kms code, you can probably fully control the timings and change the overscan/display-area via the drm api, but getting something like xorg to expose that to the user might be tricky...

[6by9]

DRM/KMS exposes the overscan margins as DRM properties.
You can modify them in X through "xrandr --set <property> <value>". "xrandr --prop" lists the available properties. They're called margin_[top|bottom|left|right] IIRC.
Note that with DRM/KMS it scales the image rather than cropping the size of the framebuffer.

[alanbork]

Note that with DRM/KMS it scales the image rather than cropping the size of the framebuffer.

Do you mean it reports full resolution but then renders that full image to a smaller rectangle, resulting in blurry output? I assume not, that sounds ugly.

[jamesh]

Note that with DRM/KMS it scales the image rather than cropping the size of the framebuffer.

Do you mean it reports full resolution but then renders that full image to a smaller rectangle, resulting in blurry output? I assume not, that sounds ugly.

It is ugly, but I believe that is the decision that the DRM/KMS designers have taken.

[alanbork]

It is ugly, but I believe that is the decision that the DRM/KMS designers have taken.

Ouch. Double ouch given that drm/kms is the future (at least for the Pi4) . probably the programmers responsible never use TVs where overscan is quite common and as such don't realize how poor that choice is.

[6by9]

It is ugly, but I believe that is the decision that the DRM/KMS designers have taken.

Ouch. Double ouch given that drm/kms is the future (at least for the Pi4) . probably the programmers responsible never use TVs where overscan is quite common and as such don't realize how poor that choice is.

It's a tough call, so I can see why they went for scaled.
How do you define overscan margins when you also support changing resolution? Do you chop the same amount off on all modes, or make it a percentage, or something else?

And how would the user react if you listed out all the resolutions as things like 1860x1008 instead of 1920x1080?

DRM/KMS allows the client to create a plane to their chosen dimensions for display on the screen. For full screen that needs to match the size of the output mode, so that really needs to be pre-cropped.

Reducing the size of the emulated frame buffer is easy enough, but that only sorts the console and console based apps, not X, and X is the main use case for the majority of users.

[alanbork]

It's a tough call, so I can see why they went for scaled.
How do you define overscan margins when you also support changing resolution? Do you chop the same amount off on all modes, or make it a percentage, or something else?

And how would the user react if you listed out all the resolutions as things like 1860x1008 instead of 1920x1080?

DRM/KMS allows the client to create a plane to their chosen dimensions for display on the screen. For full screen that needs to match the size of the output mode, so that really needs to be pre-cropped.

Reducing the size of the emulated frame buffer is easy enough, but that only sorts the console and console based apps, not X, and X is the main use case for the majority of users.

It sounds like there may be technical issues involved beyond my understanding, but from a usability perspective I'd much rather be choosing 1860x1008 from a list than suffering a blurry X11. Or perhaps more usable and useful would be a custom mode generating tool that would provide for the top and bottom clipping to be specified interactively, resulting in a saved configuration file selectable by xrandr (or whatever) that produced a pixel perfect output on your current display.

Or maybe that's the wrong part of the tool/driver chain and it should be the job of the window manager to inset the usable screen boundaries the proper amount on an underlying frame-buffer that matches the native resolution?

Unfortunately either option is really outside the scope of the raspberry pi firmware.