Bug 29723 - [SKL][HDMI] [Feature request] No overscan properties
Summary: [SKL][HDMI] [Feature request] No overscan properties
Status: REOPENED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All All
: low enhancement
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
: 30050 67027 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-21 05:47 UTC by Tom Hacohen
Modified: 2019-06-14 18:12 UTC (History)
11 users (show)

See Also:
i915 platform: ILK, SKL
i915 features: display/HDMI


Attachments
Xorg log. (154.51 KB, text/plain)
2010-08-21 05:47 UTC, Tom Hacohen
no flags Details
dmesg (36.24 KB, text/plain)
2010-08-21 05:48 UTC, Tom Hacohen
no flags Details
xrandr --prop --verbose (relevant is HDMI2) (5.52 KB, text/plain)
2010-08-21 05:49 UTC, Tom Hacohen
no flags Details
Lilliput 10" HDMI touchscreen EDID (256 bytes, application/octet-stream)
2013-08-05 14:46 UTC, Ross Burton
no flags Details
Gently ask HDMI sinks to underscan (1023 bytes, text/plain)
2013-11-27 18:25 UTC, Damien Lespiau
no flags Details
Lilliput 1011 EDID (256 bytes, application/octet-stream)
2013-11-28 17:34 UTC, Ross Burton
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Hacohen 2010-08-21 05:47:13 UTC
Created attachment 38040 [details]
Xorg log.

I don't have overscan properties. Talked to ickle on the IRC chan and he asked me to open a bug.
My Xorg-server version is 1.8.1.902 (latest on arch linux).

My system:
CP:U is core i3-530 which has the following graphic core (according to wikipedia):
Clarkdale GMCH Die:Ironlake
Wotherboard: H55M-USB3.
uname -a: Linux tompc 2.6.34-ARCH #1 SMP PREEMPT Wed Aug 11 00:23:15 CEST 2010 x86_64 Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz GenuineIntel GNU/Linux
Distro: ArchLinux x86_64
xf86-video-intel version: 2.12.0
Connector: HDMI (name HDMI2) but I guess it's relevant to all.

Attached are the Xorg log, dmesg and output of xrandr --prop --verbose.
Comment 1 Tom Hacohen 2010-08-21 05:48:22 UTC
Created attachment 38041 [details]
dmesg
Comment 2 Tom Hacohen 2010-08-21 05:49:21 UTC
Created attachment 38042 [details]
xrandr --prop --verbose (relevant is HDMI2)
Comment 3 Chris Wilson 2010-09-12 04:46:45 UTC
*** Bug 30050 has been marked as a duplicate of this bug. ***
Comment 4 Paulo Zanoni 2012-02-09 10:31:25 UTC
I will solve this problem.

For now, there are no Kernel patches, but there are tools that might help you:

- Look for the menus on your TV. Some TVs have options with weird names (like "just scan") that will turn off overscan. This won't require any patch, but won't work with all TVs.
- You can also try to use the "intel_panel_fitter" tool (patch here: http://lists.freedesktop.org/archives/intel-gfx/2012-February/014886.html) and enable the panel fitter to compensate for overscan.

You can also try to play with the AVI InfoFrames, but that's even more complicated: the kernel patches will be easier.

Maybe kernel 3.4 will have this fixed.
Comment 5 Paulo Zanoni 2012-03-23 06:00:48 UTC
Patches proposed to the dri-devel list:

http://lists.freedesktop.org/archives/dri-devel/2012-March/020342.html
http://lists.freedesktop.org/archives/dri-devel/2012-March/thread.html

New versions based on the comments will be proposed soon.

In the meantime, the "intel_panel_fitter" tool is already part of intel-gpu-tools.
Comment 6 Ross Burton 2013-06-25 15:24:04 UTC
Ping?
Comment 7 Tom Hacohen 2013-07-02 23:11:08 UTC
I have moved to a new country so I don't have access to my previous TV and setup. Unfortunately there's nothing I can do to confirm or deny the success.
Comment 8 Damien Lespiau 2013-08-05 13:13:20 UTC
ross: Could you provide the EDID of that HDMI panel? that'd be handy to see if it supports the overscan/underscan part of the infoframes.
Comment 9 Ross Burton 2013-08-05 14:46:04 UTC
Created attachment 83668 [details]
Lilliput 10" HDMI touchscreen EDID

Attached.  It's a dismal monitor.
Comment 10 Damien Lespiau 2013-08-05 14:52:48 UTC
ah, bad-ish news, this monitor doesn't support the overscan/underscan infoframe (so the work I'm doing right now won't help). It needs the next level where we play with the panel fitter to compensate the overscan on CE modes, which should come next.
Comment 11 cancan,feng 2013-08-07 05:11:51 UTC
(In reply to comment #10)
> ah, bad-ish news, this monitor doesn't support the overscan/underscan
> infoframe (so the work I'm doing right now won't help). It needs the next
> level where we play with the panel fitter to compensate the overscan on CE
> modes, which should come next.

I got a SKYWORTH 50E780U 50" TV which supports 3840x2160. I can't find kind of "scan" options in the TV settings. I'm not sure how the intel_panel_fitter works.. Could you tell me how I can know if my TV supports the overscan/underscan infoframe?
Comment 12 Damien Lespiau 2013-08-19 17:40:01 UTC
As far as I know, to support telling the sink to underscan CE modes, you need to have a video capability data block in the EDID telling you the sink can do that.

For that you need the latest version of edid-decode with the patches I just pushed: http://cgit.freedesktop.org/xorg/app/edid-decode

For a samsung TV I have around:

  Extended tag: video capability data block
    YCbCr quantization: No Data (0)
    RGB quantization: No Data (0)
    PT scan behaviour: No Data (0)
    IT scan behaviour: Support both over- and underscan (3)
    CE scan behaviour: Support both over- and underscan (3)

Your 4k TV doesn't have that, so overscans all CE modes. I think we'll need the panel fitter at that point. Now that's not as easy as it seems, the amount of overscan is not defined in the spec.
Comment 13 Damien Lespiau 2013-11-27 18:25:03 UTC
Created attachment 89911 [details]
Gently ask HDMI sinks to underscan

Hey Ross, could you test the attached patch (should apply on recent kernels, need my infoframe refactoring, say 3.12)
Comment 14 Ross Burton 2013-11-28 17:34:24 UTC
Created attachment 89962 [details]
Lilliput 1011 EDID

Sadly this doesn't work for me.  I've attached the EDID from my monitor which is aggressively overscanning when driven by a NUC.  I'm sure when I connected it to my Minnow it didn't overscan but I'll replicate that behaviour soon.
Comment 15 Jani Nikula 2014-09-05 09:10:01 UTC
It's been a long time, please retest on a recent kernel.
Comment 16 Jesse Barnes 2014-12-05 19:02:08 UTC
*** Bug 67027 has been marked as a duplicate of this bug. ***
Comment 17 Jesse Barnes 2014-12-05 19:04:31 UTC
Yeah we need both the infoframe stuff (works for some sinks) and pfit based overscan compensation.  The latter has a JIRA open for it too: VIZ-1627, which Paulo owns.  Classifying this one as an RFE.
Comment 18 N. W. 2016-11-11 22:25:23 UTC
Any update on this one?

How do you properly compensate for overscan with the Intel driver, i.e. how do you underscan?

There's a comment in a nouveau related bug saying:

> https://bugs.freedesktop.org/show_bug.cgi?id=47846#c1
> 
> Kernel 3.3 introduced underscan control
> 
> After updating, you can enable and adjust it using xrandr
> eg.
> xrandr --output HDMI-1 --set underscan on
> xrandr --output HDMI-1 --set "underscan hborder" 54 --set "underscan
> vborder" 51"

But that does not seem to work with the Intel driver.

When trying this on an i7-6700K running Ubuntu 16.04 + Oibaf PPA, i.e. with the latest git snapshots of the graphics stack (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers), it results in the following error message:

> X Error of failed request:  BadName (named color or font does not exist)
>   Major opcode of failed request:  140 (RANDR)
>   Minor opcode of failed request:  11 (RRQueryOutputProperty)
>   Serial number of failed request:  41
>   Current serial number in output stream:  41

Can someone please explain how to properly underscan?

Unfortunately there are still TVs out there which do now allow to disable overscan, so it would be important to have an option to underscan via the driver to compensate for the overscan.
Comment 19 N. W. 2016-11-15 00:35:19 UTC
No one?

Is there no way to manually configure underscan via xrandr or something like that?

Would be really appreciated if someone could help.
Comment 20 Kyle Marek 2017-01-14 23:33:22 UTC
I'm still not seeing any native options available.

It would also help if the implementation of this provided underscanning outside of X (on the kernel framebuffer), and had some kind of boot option. nouveau's implementation of xrandr --set underscan on at least applies to the framebuffers. It's not exactly usable without running X to set it, though...
Comment 21 Elizabeth 2017-07-19 19:21:53 UTC
(In reply to Paulo Zanoni from comment #4)
> I will solve this problem.
> 
> For now, there are no Kernel patches, but there are tools that might help
> you:
> 
> - Look for the menus on your TV. Some TVs have options with weird names
> (like "just scan") that will turn off overscan. This won't require any
> patch, but won't work with all TVs.
> - You can also try to use the "intel_panel_fitter" tool (patch here:
> http://lists.freedesktop.org/archives/intel-gfx/2012-February/014886.html)
> and enable the panel fitter to compensate for overscan.
> 
> You can also try to play with the AVI InfoFrames, but that's even more
> complicated: the kernel patches will be easier.
> 
> Maybe kernel 3.4 will have this fixed.

Hello,
Has this request been implemented already or it is some more information needed?
Thank you.
Comment 22 Kyle Marek 2017-07-19 19:37:35 UTC
Another thought came to mind: This *needs* to be implemented outside of X for Wayland to have underscanning.

Also, to clarify what the "this" is that I'm referring to: There are numerous TVs that do not honor overscan/underscan HDMI preferences, and do not provide any way to disable the overscanning that they are performing. The kernel framebuffer feature I am looking for is an option to force outputting an underscanned image to compensate for a display that forces overscanning on everything.
Comment 23 Jani Saarinen 2018-03-29 07:11:05 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 24 Jani Saarinen 2018-04-20 20:15:14 UTC
Ville, Shashank, is this still valid?
Comment 25 Lakshmi 2018-09-08 22:29:23 UTC
Ville, Shashank, Ping?
Comment 26 Ville Syrjala 2019-01-22 20:48:13 UTC
commit 6c4f52dca36f ("drm/connector: Allow creation of margin props alone")
decoupled the margin properties from the TV encoder stuff in drm core. Now we just need someone to hook them up to the i915 DP/HDMI/etc. code.
Comment 27 Ville Syrjala 2019-06-14 18:12:15 UTC
I typed this up a while ago:

git://github.com/vsyrjala/linux.git hdmi_margins_2
Comment 28 Ville Syrjala 2019-06-14 18:12:48 UTC
(In reply to Ville Syrjala from comment #27)
> I typed this up a while ago:
> 
> git://github.com/vsyrjala/linux.git hdmi_margins_2

Oh and despite the name this second version should work on DP too.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.