Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

PI4: Overscan doesnt work on composite output while dtoverlay=vc4-fkms-v3d is in use #1285

Closed
OlehNazar opened this issue Nov 14, 2019 · 14 comments
Closed

PI4: Overscan doesnt work on composite output while dtoverlay=vc4-fkms-v3d is in use #1285

OlehNazar opened this issue Nov 14, 2019 · 14 comments

Comments

@OlehNazar
Copy link

Hi!
I have faced with problem : I use composite video output. When parameter dtoverlay=vc4-fkms-v3d in config.txt file is active then overscan configuration doesnt take an affect. My screen is cutted and some piece of interface is out of screen. If I comment parameter #dtoverlay=vc4-fkms-v3d overscan configuration will work. "rpi-update" and update&upgrade were already performed.
I have no other possibility to use RPI4 except for composite TV out. Necessary application for me demand dtoverlay=vc4-fkms-v3d overscan so just turn off this parameter is not solution for me. If you need additional info, please contact me.
Thank you in advance!

Info:

  • PI 4 Model B 4GB

  • cat /etc/rpi-issue
    Raspberry Pi reference 2019-09-26
    Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage5

  • uname -a
    Linux raspberrypi 4.19.83-v7l+ raspberrypi-bootloader 20191021-1 breaks boot if kernel option is set #1277 SMP Mon Nov 11 16:41:20 GMT 2019 armv7l GNU/Linux

  • vcgencmd version
    Nov 8 2019 18:10:14
    Copyright (c) 2012 Broadcom
    version e3ba08775a44334ecfda5e37fafad3fb07a3dc7e (clean) (release) (start)

  • cat /boot/.firmware_revision
    d86586926cfca6aa158cab13888194d53ae23d1b

  • tvservice --status
    state 0x40000 [NTSC 14:9], 720x480 @ 60.00Hz, interlaced

config.txt
My config.txt in attachments

BR,
Oleh
@6by9
Copy link

6by9 commented Nov 15, 2019

FKMS recreates the display properties. Overscan settings can get passed through to the kernel, but I may have only done it for the HDMI displays (they have to be done by name).
I'll have a look later, but if you could post the contents of /proc/cmdline it would give the answer. Overscan would be signalled via an entry starting video=Composite-1:720x576,top_margin=X,bottom_margin=X....

@6by9
Copy link

6by9 commented Nov 15, 2019

OK, the firmware changes to add the relevant entries were trivial.

Annoyingly there's a bug in the kernel that if you insert any of the options after the refresh rate (eg 'i' for interlaced), then it incorrectly assigns all of the rest of the string as options, and then very quickly fails when it sees ','.

I've a quick fix for that, but there were a couple of cmdline parsing patches that went past on dri-devel in the last couple of days that may be a better fix. It may be safer to just push my patch anyway, and drop it again when upstream fix things.

@OlehNazar
Copy link
Author

@6by9

Thanks for your investigation.
output:
pi@raspberrypi:~ $ cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=0 cma=64M cma=256M smsc95xx.macaddr=DC:A6:32:37:4E:83 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=5e3da3da-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

If its needed I can perform tests of your patch or provide additional info

@pelwell pelwell mentioned this issue Nov 16, 2019
Closed
@ashwinterminator
Copy link

OK, the firmware changes to add the relevant entries were trivial.

Annoyingly there's a bug in the kernel that if you insert any of the options after the refresh rate (eg 'i' for interlaced), then it incorrectly assigns all of the rest of the string as options, and then very quickly fails when it sees ','.

I've a quick fix for that, but there were a couple of cmdline parsing patches that went past on dri-devel in the last couple of days that may be a better fix. It may be safer to just push my patch anyway, and drop it again when upstream fix things.

I presume this is not yet on rpi-update?

@6by9
Copy link

6by9 commented Nov 18, 2019

I presume this is not yet on rpi-update?

That would be a touch optimistic seeing as I posted at 18:45 on Friday and you're querying it 09:56 on the Monday after.

You can insert the relevant text for yourself into /boot/cmdline.txt if you're that desperate for it
video=Composite-1:720x480@60,margin_left=32,margin_right=32,margin_top=32,margin_bottom=32
Replace the 720x480@60 with 720x576@50 if you're using PAL, and the margin values as you see fit.
It appears that the kernel doesn't check the interlaced flag when comparing the defined modes against the command line mode, so the kernel issue doesn't matter if you're being lazy over your mode definition. (There should be an i after the refresh rate to denote interlaced).

@ashwinterminator
Copy link

ashwinterminator commented Nov 18, 2019 •
edited
Loading

I presume this is not yet on rpi-update?

That would be a touch optimistic seeing as I posted at 18:45 on Friday and you're querying it 09:56 on the Monday after.

Apologies if it came off that way. I was a little confused because of this: "It may be safer to just push my patch anyway, and drop it again when upstream fix things." So I wasn't sure if you had pushed it yet. Hence sought a clarification. :)

@JamesH65
Copy link
Contributor

Just a quick comment on process. Although we push stuff to our internal repo as a PR, it's still takes a day or two, or longer, for change in there to be accepted to master, and then subsequently moved in to the rpi-update system.

@ashwinterminator
Copy link

Just a quick comment on process. Although we push stuff to our internal repo as a PR, it's still takes a day or two, or longer, for change in there to be accepted to master, and then subsequently moved in to the rpi-update system.

Ah. Thank you, James. That makes the situation a lot more clear :)

@peetereczek
Copy link

I recorded the same issue on RPi 3B+ Hopefuly I'll test latest fix soon

popcornmix added a commit that referenced this issue Nov 29, 2019
@popcornmix
kernel: Bump to 4.19.86
601d36d 
kernel: configs:2711: Add V3D clock support on arm64
kernel: config: arm64: Switch to upstream cpufreq driver

kernel: arm/dts: 2711: Add 'pcie0' alias

kernel: drm/v3d: Set dma_mask as well as coherent_dma_mask

firmware: platform: Allow fixed voltage with avs_disable=1

firmware: EMMC: Use PLLD for EMMC for 250MHz host-clock
See: #1289

firmware: platform: Round down effective frequencies when they exceed max
See: #1290

firmware: arm_loader: Pass video mode via kernel command for composite
See: #1285

firmware: Fix lens shading table generation buglet
See: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=190586&start=75#p1534672

firmware: hdmi: Use RB2 timing for 2560x1440@60 if pixel clock is 241.5 MHz

firmware: arm_dt: Look for ethernet0 before ethernet

firmware: arm_dt: Set PCIe dma-ranges from memory size
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Nov 29, 2019
@popcornmix
kernel: Bump to 4.19.86
b9ecbe8 
kernel: configs:2711: Add V3D clock support on arm64
kernel: config: arm64: Switch to upstream cpufreq driver

kernel: arm/dts: 2711: Add 'pcie0' alias

kernel: drm/v3d: Set dma_mask as well as coherent_dma_mask

firmware: platform: Allow fixed voltage with avs_disable=1

firmware: EMMC: Use PLLD for EMMC for 250MHz host-clock
See: raspberrypi/firmware#1289

firmware: platform: Round down effective frequencies when they exceed max
See: raspberrypi/firmware#1290

firmware: arm_loader: Pass video mode via kernel command for composite
See: raspberrypi/firmware#1285

firmware: Fix lens shading table generation buglet
See: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=190586&start=75#p1534672

firmware: hdmi: Use RB2 timing for 2560x1440@60 if pixel clock is 241.5 MHz

firmware: arm_dt: Look for ethernet0 before ethernet

firmware: arm_dt: Set PCIe dma-ranges from memory size
@popcornmix
Copy link
Contributor

popcornmix commented Nov 29, 2019 •
edited
Loading

Can you try with latest rpi-update firmware?

edit: I think the fix is only currently on Pi4 - we'll port to Pi3 if firmware if tests are positive

@ashwinterminator
Copy link

Can you try with latest rpi-update firmware?

edit: I think the fix is only currently on Pi4 - we'll port to Pi3 if firmware if tests are positive

Just updated my Pi4

Can confirm it works! Thank you! :)

@OlehNazar
Copy link
Author

Can you try with latest rpi-update firmware?

edit: I think the fix is only currently on Pi4 - we'll port to Pi3 if firmware if tests are positive

confirm, it works on pi4

popcornmix added a commit that referenced this issue Dec 5, 2019
@popcornmix
firmware: hdmi: HDMI SM clock must not run slower than audio MAI clock
4f5f9d0 
See: #1295

firmware: arm_loader: Pass video mode via kernel command for composite (master)
See: #1285
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Dec 5, 2019
@popcornmix
firmware: hdmi: HDMI SM clock must not run slower than audio MAI clock
9300ca9 
See: raspberrypi/firmware#1295

firmware: arm_loader: Pass video mode via kernel command for composite (master)
See: raspberrypi/firmware#1285
@peetereczek
Copy link

Can you try with latest rpi-update firmware?

edit: I think the fix is only currently on Pi4 - we'll port to Pi3 if firmware if tests are positive

I was facing exactly the same issue with Pi 3B+
On latest rpi-update release all is good :)

@alanbork
Copy link

seems like this has been fixed and can be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@popcornmix @JamesH65 @6by9 @ashwinterminator @OlehNazar @peetereczek @alanbork