Bug 32450 - KMS defaults to underscan, no way to permanently turn it off
Summary: KMS defaults to underscan, no way to permanently turn it off
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: All Linux (All)
: low major
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL: http://www.phoronix.com/forums/showth...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-16 11:24 UTC by Öyvind Saether
Modified: 2011-03-23 00:09 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
only enable underscan if the TV supports audio (1.51 KB, patch)
2010-12-17 07:35 UTC, Alex Deucher
no flags Details | Splinter Review

Description Öyvind Saether 2010-12-16 11:24:34 UTC
KMS has defaulted to underscan for a while now, which is very annoying for most of us who get a black square around the picture by default.

It is possible to turn this crap off with

xrandr --output HDMI-0 --set underscan off

but that's no permanent solution. Editing the kernel source is also no good solution.

Please remove this underscan by default crap or make it possible to configure it using a kernel command line/module setting. xorg.conf setting would be better than nothing but still no good solution when not using X.

I know some developers insist on shooting themselves in the foot by forcing this underscan shit on everybody. Forum posts by numerous people indicate that most users hate this shit as much as I do. Thank you for reading all of this. Have a nice christmas.
Comment 1 Daniel Stone 2010-12-16 14:57:24 UTC
On Thu, Dec 16, 2010 at 11:24:35AM -0800, bugzilla-daemon@freedesktop.org wrote:
> I know some developers insist on shooting themselves in the foot by forcing
> this underscan shit on everybody. Forum posts by numerous people indicate that
> most users hate this shit as much as I do. Thank you for reading all of this.
> Have a nice christmas.

Thanks for being so polite and friendly - merry Christmas to you too.
Comment 2 Jeremy 2010-12-16 15:38:47 UTC
Well, I for one appreciate the work you guys do, and understand that you didn't choose this as default behaviour to deliberately annoy anyone. So without being rude about it, I do agree that if 1:1 pixel mapping isn't possible as defualt, it would be nice if there was a way to set the behaviour permanently and without needing to run X.
Comment 3 Michel Dänzer 2010-12-17 01:01:44 UTC
While the wording of this report is out of line, I tend to agree that underscan enabled is the wrong default based on the principle of least surprise: People connecting PCs to TVs (presumably the relative minority) are likely to be aware of overscan as a potential issue, whereas people connecting PCs to monitors (presumably the relative majority) may not know anything about it.

That said, I suspect there will be people asking for a way to override the default from the start, no matter what the default is...
Comment 4 Roland Scheidegger 2010-12-17 06:25:27 UTC
I'm wondering, would it be possible to guess if the connected device is a TV and thus likely to need underscan? Things like presence of interlaced resolutions in the edid data maybe? Dot pitch?
In any case, I agree with Michel. Underscan by default seems wrong, and a better way to override would be nice.
Comment 5 Alex Deucher 2010-12-17 07:07:36 UTC
I have a couple ideas.  First would be to check if the cea edid extention block contained audio bits, and only enable underscan if the audio bits were there as if there are audio bits there's likely a TV attached.  Secondly, it would be nice to expose the connector attributes via sysfs rather than only via ioctl.
Comment 6 Alex Deucher 2010-12-17 07:35:50 UTC
Created attachment 41213 [details] [review]
only enable underscan if the TV supports audio

This should help the plain monitor case.  Exposing connectors attributes via sysfs is a larger task and I don't have time to do it right now.  It doesn't require any hardware knowledge so it would be a good task for someone that wants to help out with kms.
Comment 7 DH 2010-12-20 06:51:42 UTC
How about adding a proper solution for people who own TV's that are under 10 years old and are able to output full native resolution of 1920x1080 without any form of scaling? These devices account for a MAJORITY of LCD/LED TV's supporting 1920x1080 resolution.

I.e., underscan should be disabled by default and only ENABLED if some specific steps are taken.


And for that matter, aren't the majority of people hooking up to TV's using it for HTPC purposes? I.e. something along the lines of MYTHTV or XBMC, for which *overscan* is actually suitable. There is actually a *reason* why some TV's overscan (ALL older TV's....) and that is so the video images extend all the way to the edge of the display. Media interfaces are designed with this in mind and have a significant border region before you reach the actual controls.


Having it underscan by default completely breaks *EVERYTHING* and fights against the purpose of overscan to begin with. The result is that the image is scaled when it shouldn't be, and that there is a big ugly black border around the periphery, when overscan is ***supposed*** to eliminate that.
Comment 8 DH 2010-12-20 06:55:21 UTC
As I see it, there are two options;
1) get rid of underscan-by-default, it is WRONG.
2) in the VERY least, provide a mechanism that can be used by people who want *correct* behavior despite INCORRECT defaults.


Both options are easy and do NOT require sysfs or complex weird things.
A simple kernel parameter, radeon.underscan=off would solve all the problems. Anybody who wants broken behavior can simply leave it out.
Comment 9 Michael 2010-12-23 11:10:39 UTC
First I want to express the respect I owe you guys for spending precious time on free code. Many thanks ! You deserve it!

Second, I understand that you copied the behaviour of frglx and activate underscan by default.

Third, I want to kindly ask you to change the default to 1:1 display. Overscan is simply wrong if you're connecting a PC to a TV. TVs are doing overscan to respect the corrupt first or last lines that are used in TV signal to transmit information (I heard that - it may be nonsense). Some TVs always oversan. That is the ONLY case where undescan makes sense. But Monitors with 1080p resolution, TVs without overscan (or overscan turned off) are more common cases when it comes to PC displays.

I think in a perfect world, you would make 1:1 display default. To handle TVs attached to PCs you could do some magic - if:

- display reports TV-like resolutions (interlaced)
- display reports audio capabilities
- display name has TV in it - sample:

michael@michael-desktop:/var/log$ grep TV Xorg.0.log
[    34.610] (II) RADEON(0): Monitor name: Panasonic-TV

If all that (or most) is true than you might enable underscan by default. You could also check versus a underscan positive list where you put devices in which can't disable overscan.

Thanks for reading, merry christmas and a happy new year!!!
Comment 10 Alex Deucher 2010-12-23 11:58:24 UTC
(In reply to comment #9)
> I think in a perfect world, you would make 1:1 display default. To handle TVs
> attached to PCs you could do some magic - if:
> 
> - display reports TV-like resolutions (interlaced)
> - display reports audio capabilities
> - display name has TV in it - sample:

This is more or less what the patch in comment 6 does (only enables audio if the display supports audio).  The problem with TV-like modes is that monitors likely support them as well, and as for EDID strings, they are too inconsistent.
Comment 11 Alex Deucher 2010-12-23 12:01:55 UTC
only enables *underscan* if the display supports audio
Comment 12 Öyvind Saether 2010-12-23 19:53:01 UTC
Point 1) My monitor supports AUDIO. It does NOT have the speakers, it's got this headphone jack and I can (ab)use that as "HDA ATI HDMI" output.
Point 2) I do not want the underscan.

Thus, "only enables *underscan* if the display supports audio" is not a solution which works for me. This "solution" may work for other people who have no HDMI audio support, but it will not help me at all.

I am therefore strongly against using this to check for those who have a 10 year old television which needs this underscan for some reason.
Comment 13 Douglas Beach 2011-02-21 14:17:03 UTC
Re-opening, as I don't consider checking for audio to be a fix, since the current behavior is a problem for me on my Sony LCD TV, which of course has audio. Currently I'm using the xrandr workaround, but reading the screen when I first boot up is actually pretty difficult with the badly scaled text. A kernel command option would be a real fix.
Comment 14 Alex Deucher 2011-02-21 14:57:56 UTC
(In reply to comment #13)
> Re-opening, as I don't consider checking for audio to be a fix, since the
> current behavior is a problem for me on my Sony LCD TV, which of course has
> audio. Currently I'm using the xrandr workaround, but reading the screen when I
> first boot up is actually pretty difficult with the badly scaled text. A kernel
> command option would be a real fix.

underscan is disabled by default in 2.6.38:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=56bec7c009872ef33fe452ea75fecba481351b44
Comment 15 Douglas Beach 2011-02-22 11:04:26 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > Re-opening, as I don't consider checking for audio to be a fix, since the
> > current behavior is a problem for me on my Sony LCD TV, which of course has
> > audio. Currently I'm using the xrandr workaround, but reading the screen when I
> > first boot up is actually pretty difficult with the badly scaled text. A kernel
> > command option would be a real fix.
> 
> underscan is disabled by default in 2.6.38:
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=56bec7c009872ef33fe452ea75fecba481351b44

Sorry, just read the changelog this morning and saw that. Thanks.
Comment 16 Anthony Bourguignon 2011-03-22 03:42:35 UTC
Hello,

I'm still having this behavior (underscan is on by default) even if I'm using kernel 2.6.28.
Did I miss something ?

Sincerrely
Comment 17 Rafał Miłecki 2011-03-22 04:44:09 UTC
(In reply to comment #16)
> Hello,
> 
> I'm still having this behavior (underscan is on by default) even if I'm using
> kernel 2.6.28.
> Did I miss something ?

2.6.28 or 2.6.38?
Comment 18 Anthony Bourguignon 2011-03-22 04:55:01 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > Hello,
> > 
> > I'm still having this behavior (underscan is on by default) even if I'm using
> > kernel 2.6.28.
> > Did I miss something ?
> 
> 2.6.28 or 2.6.38?

It's 2.6.38. Sorry about the mistake.
Comment 19 Michel Dänzer 2011-03-22 05:02:04 UTC
(In reply to comment #16)
> I'm still having this behavior (underscan is on by default) even if I'm using
> kernel 2.6.28.
> Did I miss something ?

Is what you're seeing really underscan by the GPU and no overscan by the TV (resulting in black borders around the image), not the other way around (resulting in the border area of the image being invisible)?
Comment 20 Rafał Miłecki 2011-03-22 05:03:05 UTC
(In reply to comment #18)
> It's 2.6.38. Sorry about the mistake.

Please, provide output of "xrandr --prop" with connected TV.

Do you have black borders on TV or are you missing some image on TV?
Comment 21 Anthony Bourguignon 2011-03-22 05:15:57 UTC
(In reply to comment #19)
> Is what you're seeing really underscan by the GPU and no overscan by the TV
> (resulting in black borders around the image), not the other way around
> (resulting in the border area of the image being invisible)?

It's really underscan. I've got black borders around the image. For your information, I'm having this issue with an ATI Radeon 4350 and a Hanns G HH251HP monitor. The problem is resolved with the xrandr command that disable underscan.

(In reply to comment #20)
> Please, provide output of "xrandr --prop" with connected TV.
> 
> Do you have black borders on TV or are you missing some image on TV?

I've got no access to my computer right now. I will post the result later.
As I said, I'm seeing black borders.
Comment 22 Anthony Bourguignon 2011-03-22 11:43:43 UTC
I've made a few more tests. I thought that underscan was going off in 2.6.38 because of a xrandr command I've put in gdm3 Init script. Here are my results, without this trick :

With kernel 2.6.37, when the kernel boots, the console is using the native resolution (1920x1080) but it seems that underscan is on (black borders are present). When X.org is starting, it's still the same.

With kernel 2.6.38, underscan is still present at boot time, with black borders, but when X.org starts, underscan is going off automatically.

So my question is, is it a normal behavior ? Should underscan being on at boot time and off after X is started ? I'm expecting it to be off even in console, when the system starts.
Comment 23 Alex Deucher 2011-03-22 13:11:20 UTC
The vbios underscans hdmi by default to deal with overscanning TVs.  Once the radeon driver has loaded, it is off by default.
Comment 24 Anthony Bourguignon 2011-03-22 14:29:10 UTC
(In reply to comment #23)
> The vbios underscans hdmi by default to deal with overscanning TVs.  Once the
> radeon driver has loaded, it is off by default.

It is possible or planned that the default behavior, even for the vbios, is to be off by default ?
Comment 25 Alex Deucher 2011-03-22 15:24:06 UTC
(In reply to comment #24)
> (In reply to comment #23)
> > The vbios underscans hdmi by default to deal with overscanning TVs.  Once the
> > radeon driver has loaded, it is off by default.
> 
> It is possible or planned that the default behavior, even for the vbios, is to
> be off by default ?

The default behavior for the driver is underscan off by default in 2.6.38.  We can't do anything about the vbios.  The vbios is only a factor before the driver loads (i.e., during post and grub).  Once the driver has loaded, X and the console have underscan off by default.
Comment 26 Anthony Bourguignon 2011-03-23 00:09:49 UTC
Ok, I understand.

Thanks


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.