overscan trouble after update

[sergiopoverony]

https://retropie.org.uk/forum/topic/22790/overscan_-not-work-after-update-4-5-in-emulationstation

[6by9]

You get presented with a template when you create a new issue. Please use it.

If using a Pi4 then overscan is not currently supported through FKMS, and never has been through FKMS/KMS on Pi0-3.

[sergiopoverony]

You get presented with a template when you create a new issue. Please use it.

If using a Pi4 then overscan is not currently supported through FKMS, and never has been through FKMS/KMS on Pi0-3.

Pi3A+, Pi3B+, PiZeroW

[popcornmix]

I think from reading the linked thread that overscan_scale=1 stopped working with a recent update.
(I believe legacy mode - console is okay, but dispmanx layers aren't scaled).

A clear description of the issue would be helpful.

[sergiopoverony]

A clear description of the issue would be helpful.

delete overscan_scale=1 ot not,,, any time this bug, I think this is bug from prepi4
In forum more users can have bug

[6by9]

delete overscan_scale=1 ot not,,, any time this bug, I think this is bug from prepi4
In forum more users can have bug

I know English may not be your first language, but that makes no sense.
There may well be a bug, but you have still not provided any details.

In the template it asks for the following system information.

System
Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a > pastebin link, or add answers to the following questions:

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
• Which OS and version (cat /etc/rpi-issue)?
• Which firmware version (vcgencmd version)?
• Which kernel version (uname -a)?

Logs
If applicable, add the relevant output from dmesg or similar.

Additional context
Add any other relevant context for the problem.

You've provided the model, but nothing else.

I can have a guess at what you're doing, but without more information from you I won't be investigating beyond my current ongoing developments.

I'm guessing that you have dtoverlay=vc4-fkms-v3d in config.txt to load the fkms driver (dmesg would have confirmed this). FKMS has been significantly updated to use the mainline kernel mode selection, however this means that the firmware has no chance to intercept the requested mode and trim it for overscan. (My earlier statement was wrong, previous versions of FKMS would present the trimmed framebuffer size as the one mode).
The mainline Linux kernel has only gained overscan support in the 5.1 release, and even then it is only scaling the planes (effectively overscan_scale=1 always). I am looking at backporting it, but it isn't ready yet.

The issue I have with that is that lots of the forums posts are referencing fbset, which is for the old framebuffer API. WIthout a clear description of what you are trying to do and how it is set up, I'll be chasing my tail looking through the whole system.

[sergiopoverony]

1. Raspberry Pi 3A+, 3B, 3B+, Zero W
2. Raspberry Pi reference 2018-03-13
   Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 00013d7972122d1304aacda8fff5098f073ceb43, stage2
3. Jun 20 2019 16:12:41
   Copyright (c) 2012 Broadcom
   version a59fb7a74180be0111dbc5c18a37ec6df86f14a3 (clean) (release) (start)
4. Linux retropie 4.19.50+ dts: overlay: add generic support for ads7846 #896 Thu Jun 20 16:09:52 BST 2019 armv6l GNU/Linux

Config special big digits for overlay_left https://pastebin.com/SN7183V3
Dmesg - https://pastebin.com/hEEHTxLX

dtoverlay=vc4-fkms-v3d - not used

GO ON )

[6by9]

Testing with Raspbian, all looks fine.

As per raspberrypi/firmware#591 (comment), what are you expecting negative overscan offsets to achieve? They are absolute offsets against the defined dispay mode, so negative means part of the frame buffer is never displayed.

overscan_[left|top|right|bottom] all seem to work sensibly for me as long as disable_overscan=0.

Reading the code in more detail, it appears to also be disabled for DMT display modes (ie hdmi_group=2). That seems logical as DMT are intended for monitors which should never underscan, only CEA TV modes should ever underscan.
The same condition was in the old code, but various things have been shifted around for the multiple frame buffer support, therefore behaviour may have changed.

[6by9]

OK, I now vaguely understand the code, and the behaviour has changed slightly.

disable_overscan=1 used to disable the level of overscan that the firmware would apply on CEA modes. This is 32 pixels for modes <1280 wide, or 48 pixels otherwise.

overscan_[left|top|right|bottom] were on top of the firmware applied overscan, therefore negative values will reduce the firmware's overscan, but clipped at 0 adjustment. (The better solution is to set disable_overscan=1 and set your own absolute values).

With latest firmwares disable_overscan=1 disables overscan totally, and overscan is automatically disabled on DMT modes.

From your report I still can't tell whether this is actually your problem, but patches are up to reinstate that behaviour.

[sergiopoverony]

OK, I now vaguely understand the code, and the behaviour has changed slightly.

Now i understand. Thank you