commit 039ed2d9a24b3c4e272439b1551762fcb77c188a enables underscan if the mode is a typical TV one. But almost every widescreen monitor in the 22"-24" range uses 1080p, and most of them support HDMI. It seems really strange to me that the most common case of a 1080p display is a TV, so the commit should be reverted or limited to non-1080p modes.
I totally agree after testing that newer kernels with SONY BRAVIA 52'' 1080p (firmware: 2.14.581). Driver enables underscan when using "auto" on this TV. 1) In default mode "Wide" I get black borders 2) In "Zoom max." I get black border on bottom and top, left, right are cut 3) In "14:9" left and right black border, top and bottom cut 4) In "Smart" overzoomed (all sides cut) 5) In "4:3" huge black border and scaled without proportions
Unfortunately, there's no way for the driver to know whether the TV has overscan enabled or not or if the TV is in some special scaling mode enabled. Lots of TV's have no option to disable overscan. As such, the driver underscans the image to compensate for the overscan; this is limited to the common HD modes. Unfortunately, there's no good answer. Before I added underscan support to the driver, I got bug reports from people with TV's where the image was cut off on the edges due to the TV overscanning. You can disable underscan in the driver with: xrandr --output <output> --set underscan off
I know, but my point is that there are too many displays that use 1080p to choose underscan by default. Also, TVs that show the "HD Ready 1080p" logo are required to support a mode that doesn't overscan ([0], p. 13). Besides, if I understand it correctly, underscanning is really just a workaround that produces blurred images. Underscan support is fine, but I don't think it should be enabled by default with such a (necessarily) approximative euristic. [0] http://www.digitaleurope.org/fileadmin/user_upload/document/HD_ready_1080p_1188470475.pdf
(In reply to comment #3) > I know, but my point is that there are too many displays that use 1080p to > choose underscan by default. There are a lot of 1080P TVs too and most of them overscan by default. In fact, I would say the vast majority of new TVs are 1080p. Probably more TVs than monitors. > Also, TVs that show the "HD Ready 1080p" logo are required to support a mode > that doesn't overscan ([0], p. 13). In practice that doesn't seem to be the case. There seem to be quite a few vendors that do not provide a non-overscanned mode or they hide the mechanism to disable it well enough that most users can't find it. Either way, overscan is always the default on TVs.
I tried a really tentative benchmarc looking for "LCD monitor" and "LCD monitor 1080 HDMI" among computer monitors on google products. 1080p HDMI monitors are 10000 out of 95000, more than any other resolution but 1280x1024 (13000, regardless of connection type) I think this will do more harm than good, but I see how this is a judgement call. Still, wouldn't it be better to have a way disable it via a proper setting (xorg.conf) instead of using Xsession? Also, a way to disable underscanning even if X isn't running could be nice (though I guess someone using text only on a HDMI screen isn't really a common use case)
It sucks for everyone ;) It would be nice if there was an EDID flag for overscan. I would be a good idea to expose connector properties via xorg.conf and additionally via sysfs, but it's a fair amount of work and I haven't had time to work on it unfortunately.
Hmmm, even with what seems to be overscan (hdsize) on my tv, the image would not fit properly (but better than without it) and still be blury, whereas using the xrandr command you gave everything went back to normal.
Just got a new radeon card today and got bitten by this. The display is connected via DVI too, so the new underscan default is not limited to HDMI. Would it be feasible to add a module parameter that could be used to disable the default underscan? That way you could at least get a sane resolution before X is started...
[PATCH] drm/radeon/kms: disable underscan by default http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg06695.html http://permalink.gmane.org/gmane.comp.video.dri.devel/53051 This is in drm-next already: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=56bec7c009872ef33fe452ea75fecba481351b44
*** Bug 20982 has been marked as a duplicate of this bug. ***