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.
Created attachment 38041 [details] dmesg
Created attachment 38042 [details] xrandr --prop --verbose (relevant is HDMI2)
*** Bug 30050 has been marked as a duplicate of this bug. ***
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.
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.
Ping?
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.
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.
Created attachment 83668 [details] Lilliput 10" HDMI touchscreen EDID Attached. It's a dismal monitor.
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.
(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?
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.
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)
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.
It's been a long time, please retest on a recent kernel.
*** Bug 67027 has been marked as a duplicate of this bug. ***
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.
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.
No one? Is there no way to manually configure underscan via xrandr or something like that? Would be really appreciated if someone could help.
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...
(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.
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.
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.
Ville, Shashank, is this still valid?
Ville, Shashank, Ping?
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.
I typed this up a while ago: git://github.com/vsyrjala/linux.git hdmi_margins_2
(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.
You are reporter of the issue currently having low priority. Do you still see issue. If so, please spesify clearly what is impact to you.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/19.
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.