If you set some cropped mode like 1856x1016 like you suggested, we'd get a ton of bug reports about the driver not detecting the proper mode, "my tv is 1920x1080, but the driver detects 1856x1016", etc.
As I've said before, there no good solution to this problem that works for every case.
I.e., you are breaking the driver to sort-of (hackishly) fix hardware that really isn't designed to do this, whereas there IS a lot of hardware that IS designed to be able to do this.
I'm really not certain how you can justify breaking support for COMPATIBLE hardware in favor of INCOMPATIBLE hardware, because that is what is happening.
That fact is not in dispute. The issue is regarding what the panel *actually* is, which is not necessarily related to the input you feed into it. If the panel itself is ACTUALLY 1856x1016 (or whatever), it doesn't mean that you can't feed it 1920x1080. The TV will do its voodoo and output whatever it feels like -- which is actually a SMARTER way to do overscan since it doesn't require scaling to begin with. It results in superior picture quality than you would end up with by taking a 1920x1080 input, cropping the edges, and scaling it back up to 1920x1080.Panels have fixed timing and a fixed number of pixels in the panel. Unless the vendor decided to hide some of the pixels behind the bezel, they are all visible on the screen.
Right...For every mode other that the native mode, TVs use a scaler to scale the image so that the panel always displays the native timing. For overscan, the TV scales the image up slightly; if the panel is 1920x1080 and you feed it 1280x720, it scales the image up to 1920x1080, etc.
Here's the thing though... if the panel has a native mode of 1920x1080 and it ALWAYS overscans, then there is no input in the world that will actually be displayed without some kind of scaling. Feeding it 1920x1080, the input would be scaled up to OVER 1920x1080 and cropped (or cropped first and then scaled)... which appears to be what most newer TV's actually do in their default state (mine does). The ONLY way for the TV to map its input to panel pixel-to-pixel without any kind of scaling AND STILL achieve overscan is to either have a native panel resolution LOWER than 1920x1080 and crop, OR to hide pixels around the outside.
So... do ALL TV's scale up and crop for overscan? Or do some have a smaller native resolution and JUST crop?
The point is, that you don't necessarily KNOW the actual native mode of the panel based on what you get out of the EDID since the TV can do its own scaling without telling you.
The second point is obviously that it is BETTER to feed in some form of unscaled image for devices that *are* able to map input to panel 1:1, which includes all TV's where you have the option to display native mode and have a REAL resolution of 1920x1080, as well as all devices that use either a smaller panel resolution or hiding pixels methods for achieving overscan.... and these two options certainly must cover the majority of digital TV's, since it would be just braindead to develop a TV that CAN'T operate without scaling the image.
That's not quite what I suggested. I suggested sending the TV an actual 1080p that IS underscanned, but withOUT scaling anything, and there are two ways to accomplish this that I can see; either by the driver presenting a FAKE SMALLER MODE and performing voodoo, *OR* by getting the xserver to deal with it.If you set some cropped mode like 1856x1016 like you suggested,
Invalid bug reports are part of the business, aren't they? I figure that as long as it is documented clearly, it should be obvious to anyone but the most complete morons.we'd get a ton of bug reports about the driver not detecting the proper mode, "my tv is 1920x1080, but the driver detects 1856x1016", etc.
True, you can never totally satisfy everyone, but the way it is now vs 2.6.35 and older is probably 45/45/10 (with that last 10 not liking either option). You can get that up to 90/10 simply by giving the user the ability to choose one or the other. And it is EASY... and can allow the DEFAULT behavior to remain as it is right now.... just a simple module parameter to globally disable underscan. That would satisfy everyone with a proper display that can operate without any form of scaling or cropping, and everyone who doesn't mind scaled input.As I've said before, there no good solution to this problem that works for every case.
The only people it won't satisfy are those who have two TV's with differing input requirements, or those whose TV's have a visible resolution lower than the *reported* native mode who COULD have 1:1 output. And these people, of course, are already unsatisfied.
In the very least, there really should be support for people whose hardware is actually compatible....
Scaling is how both the tv and the driver deal with overscan, it just depends who does the scaling. It's not some crazy hack. That's how you compensate for it if you want to retain the entire image. Before I added the underscan option, users with TVs with overscan were unhappy and now users with TVs without overscan are unhappy. You can disable underscan if you don't like it, that's why I added a knob. Now everyone can be happy.
I would be happy if I could disable it in some permanent way in xorg.conf not xrandr every time I start X
+1 for kernel parameter, I often don't go into X at all...
Over here in Japan, i'd say 75% of the monitors in the computer shops are 16:9 1080p. All of the ones I have experience with have issues with being underscanned for no reason. This is not just on the Radeon driver, but on the Catalyst driver as well. With Catalyst you can disable underscan once and forget about it. I support the notion that the Radeon driver should be able to do the same, via one of the methods mentioned above. Doing it every time via xrandr is just a pain. Newer panels just don't need it.
At least you can recompile your kernel with all instances of "UNDERSCAN_AUTO" replaced with "UNDERSCAN_OFF".... but that IS a REAL PAIN.
Broken, broken, broken....
Note: Everybody who has this problem should create a bug report at somewhere that will be read, like kernel or freedesktop.