Overscan issue with OpenGL driver. #42
Comments
|
The open driver scans out pixels 1:1, and it has no way to see the contents of your config.txt Many TVs default to scaling from a subset of the screen, so rather than telling everyone to go in their TV settings to make it scan pixels 1:1 (or use the "PC" HDMI plug), the config.txt overscan fields make the HVS scale the screen contents down to a smaller area, so that it hopefully lines up with where your TV is scaling up from. This will hurt image quality, but it's a workaround. Nouveau and Radeon have underscan KMS properties that do scaling like the old config.txt entries to support those TVs, so I should add those properties too. |
|
Interesting, I thought I'd configured the TV not to scale at all. |
|
Can you attach your xrandr --verbose output? I'm curious what your CEA block reports. |
|
With current drm-next, some displays may be better behaved about overscan. |
|
Hi sorry for the delay, will try to get this to you this week. |
|
I've attached the results both with and without the opengl driver. Let me know if you need anything else. |
|
I experience the same issue on Raspbian Stretch 2019-04-08 + Samsung TV. |
|
@deuteragenie On some Samsung TVs, labeling the HDMI input used for the Pi as PC (or whatever it is called in their menus) will help fix image issues. |
Thomas has noticed the following NULL ptr dereference when using cgroup v1 kmem limit: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 3 PID: 16923 Comm: gtk-update-icon Not tainted 4.19.51 #42 Hardware name: Gigabyte Technology Co., Ltd. Z97X-Gaming G1/Z97X-Gaming G1, BIOS F9 07/31/2015 RIP: 0010:create_empty_buffers+0x24/0x100 Code: cd 0f 1f 44 00 00 0f 1f 44 00 00 41 54 49 89 d4 ba 01 00 00 00 55 53 48 89 fb e8 97 fe ff ff 48 89 c5 48 89 c2 eb 03 48 89 ca <48> 8b 4a 08 4c 09 22 48 85 c9 75 f1 48 89 6a 08 48 8b 43 18 48 8d RSP: 0018:ffff927ac1b37bf8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: fffff2d4429fd740 RCX: 0000000100097149 RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff9075a99fbe00 RBP: 0000000000000000 R08: fffff2d440949cc8 R09: 00000000000960c0 R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000 R13: ffff907601f18360 R14: 0000000000002000 R15: 0000000000001000 FS: 00007fb55b288bc0(0000) GS:ffff90761f8c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000007aebc002 CR4: 00000000001606e0 Call Trace: create_page_buffers+0x4d/0x60 __block_write_begin_int+0x8e/0x5a0 ? ext4_inode_attach_jinode.part.82+0xb0/0xb0 ? jbd2__journal_start+0xd7/0x1f0 ext4_da_write_begin+0x112/0x3d0 generic_perform_write+0xf1/0x1b0 ? file_update_time+0x70/0x140 __generic_file_write_iter+0x141/0x1a0 ext4_file_write_iter+0xef/0x3b0 __vfs_write+0x17e/0x1e0 vfs_write+0xa5/0x1a0 ksys_write+0x57/0xd0 do_syscall_64+0x55/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Tetsuo then noticed that this is because the __memcg_kmem_charge_memcg fails __GFP_NOFAIL charge when the kmem limit is reached. This is a wrong behavior because nofail allocations are not allowed to fail. Normal charge path simply forces the charge even if that means to cross the limit. Kmem accounting should be doing the same. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Michal Hocko <[email protected]> Reported-by: Thomas Lindroth <[email protected]> Debugged-by: Tetsuo Handa <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Vladimir Davydov <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Thomas Lindroth <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
|
Still not solved. I just installed new Raspberry Pi OS which is Bullseye which has this driver now enabled by default, its not experimental anymore and issue is still here. If I turn it off, overscan configurations I set in /home/config.txt work just fine but if I enable it, it doesn't work. I am using RPi 3b+ on CRT tv using composite cable I had no issues with Raspbian Buster or any other version of the OS before, but now... I can't believe it, this is some Microsoft and Bethesda shit right here folks, push non working stuff as default for everyone to use. |
Hi
I hope this is the correct place to report this, I have done some searching and not found anything relating to this issue.
When running Raspbian without the OpenGL driver to my Full HD TV (via HDMI) we can see the entire screen, both at bootup and when running X.
When we swap over to the OpenGL driver the image extends past the edge of the TV on all sides, both on the console at bootup and when running X.
Changing the overscan options from raspi-config has no effect.
Changing the overscan_{left|right|top|bottom} and the disable_overscan in config.txt, has no effect.
Am I just missing the obvious, configured wrong, or is this a bug?
Let me know what information you require and I will get it for you.
Thank you for all your hard work getting this driver working :-)
The text was updated successfully, but these errors were encountered: