Created attachment 59007 [details] edid & log file I get overscan (areas of the image outside the tv) in every direction when using my nvidia 9400 + nouveau (git checkout from 2012-03-21) and a Sharp TV. With the proprietary nvidia module the size is perfect. I'm attaching the edid info that I got from the nvidia-settings program and an Xorg log file with increased verbosity.
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" Would you mind giving it a try Cheers Emil
(In reply to comment #1) > 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" > > Would you mind giving it a try > > Cheers > Emil I will try that, however the boot messages and console is also cropped, it would be better to have this working from the beginning.
(In reply to comment #1) > 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" > > Would you mind giving it a try Ok, those commands do help and after trial and error I can find the correct values to use. However, I would much rather have this working from boot time. I can already picture myself starting X just to run xrandr and fix the overscan and then going back to the console. If its not possible to fix the root problem (EDID), it would be great to be able to specify these underscan parameters to the kernel module. The ideal situation would be to do both things :) Now I have a new problem that I didn't have with nvidia proprietary driver. When running a fullscreen application, I get this: X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 129 (XFree86-VidModeExtension) Minor opcode of failed request: 10 (XF86VidModeSwitchToMode) Value in failed request: 0x167 Serial number of failed request: 149 Current serial number in output stream: 151 I guess I'll open another bug report if I can't solve it by myself. Thanks for your help, can't wait to see this fixed.
(In reply to comment #3) > If its not possible to fix the root problem (EDID)... A quick check indicates that there is no obvious "fix" in the EDID There is a section of the EIA/CEA-861 extension block that indicates if underscan is supported or not, but no exact numbers (dimensions etc.) are specified IMHO there should be a drm core function that parses the flag and deals with it accordingly > able to specify these underscan parameters to the kernel module. Please feel free to send us an RFC/patch :) > Now I have a new problem that I didn't have with nvidia proprietary driver. > When running a fullscreen application, I get this: > > X Error of failed request: BadValue (integer parameter out of range for > operation) > ... > I guess I'll open another bug report if I can't solve it by myself. This is a separate issue, please provide more information in the newly opened bug report - dmesg, Xorg.0.log, application name etc.
After playing with xrandr and this new underscan parameter I have concluded this is just an ugly workaround that doesn't fix the root problem which is getting EDID right. Everything still looks wrong, I think the problem is that by using this underscan thing the applications still think the resolution is 1366x768 when its no longer the case. And of course there is also the overscan at boot time problem. So is there any way to fix the way nouveau interprets the EDID data to make it work like nvidia's driver?
(In reply to comment #5) > After playing with xrandr and this new underscan parameter I have concluded > this is just an ugly workaround that doesn't fix the root problem which is > getting EDID right. > > Everything still looks wrong, I think the problem is that by using this > underscan thing the applications still think the resolution is 1366x768 when > its no longer the case. > And of course there is also the overscan at boot time problem. > > So is there any way to fix the way nouveau interprets the EDID data to make it > work like nvidia's driver? I'll add this to my list to look at. There is some hints in the EDID extension blocks that say whether or not a display will overscan a given resolution or not, and flags in the AVI InfoFrame that can (possibly) control it too. I looked into this at some point, and couldn't find a device that actually obeyed the specs so I didn't bother in the end. It's possible the NVIDIA binary driver is doing this I guess. However, for most displays, even with the NVIDIA binary driver you have to use their "Overscan Compensation" option too..
Does the patch in this bug help? https://bugzilla.redhat.com/show_bug.cgi?id=806091 You'll need to add "nouveau.hdmi_disable=HDMI-1" (without the quotes) to your kernel command line.
(In reply to comment #7) > Does the patch in this bug help? > > https://bugzilla.redhat.com/show_bug.cgi?id=806091 > > You'll need to add "nouveau.hdmi_disable=HDMI-1" (without the quotes) to your > kernel command line. I don't think the is the same as your issue Ian. A great deal of HDMI TVs and monitors will overscan regardless, and the only way to fix that is either the magic bits in the AVI InfoFrame (if you're lucky enough to have a monitor that cares), or to use the overscan compensation options.
(In reply to comment #7) > Does the patch in this bug help? > > https://bugzilla.redhat.com/show_bug.cgi?id=806091 > > You'll need to add "nouveau.hdmi_disable=HDMI-1" (without the quotes) to your > kernel command line. Thanks anyway, but it didn't work. I used nouveau.hdmi_disable=all, got this in my kernel messages: [drm] nouveau 0000:02:00.0: disabling HDMI functions on output VGA-1 [drm] nouveau 0000:02:00.0: disabling HDMI functions on output HDMI-A-1 But the overscan is still there. I just realized I never posted my kernel messages before, so here it is: bash$ dmesg |grep -i nouv Kernel command line: pcie_aspm=force root=/dev/sda2 ro initrd_root=/dev/ssd/root quiet nouveau.hdmi_disable=all nouveau 0000:02:00.0: setting latency timer to 64 [drm] nouveau 0000:02:00.0: Detected an NV50 generation card (0x0ac500b1) [drm] nouveau 0000:02:00.0: Attempting to load BIOS image from PRAMIN [drm] nouveau 0000:02:00.0: ... appears to be valid [drm] nouveau 0000:02:00.0: BIT BIOS found [drm] nouveau 0000:02:00.0: Bios version 62.79.3c.00 [drm] nouveau 0000:02:00.0: TMDS table version 2.0 [drm] nouveau 0000:02:00.0: MXM: no VBIOS data, nothing to do [drm] nouveau 0000:02:00.0: DCB version 4.0 [drm] nouveau 0000:02:00.0: DCB outp 00: 01000300 0000001e [drm] nouveau 0000:02:00.0: DCB outp 01: 01011322 00020010 [drm] nouveau 0000:02:00.0: DCB conn 00: 00000000 [drm] nouveau 0000:02:00.0: DCB conn 01: 00001161 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 0 at offset 0xDB11 [drm] nouveau 0000:02:00.0: Register 0x00004028 not found in PLL limits table [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 1 at offset 0xDDC5 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 2 at offset 0xDDC7 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 3 at offset 0xDEAC [drm] nouveau 0000:02:00.0: Parsing VBIOS init table 4 at offset 0xDF71 [drm] nouveau 0000:02:00.0: Parsing VBIOS init table at offset 0xDFD6 [drm] nouveau 0000:02:00.0: 0xDFD6: Condition still not met after 20ms, skipping following opcodes [drm] nouveau 0000:02:00.0: 1 available performance level(s) [drm] nouveau 0000:02:00.0: 3: core 580MHz shader 1400MHz voltage 1200mV fanspeed 100% [drm] nouveau 0000:02:00.0: c: [drm] nouveau 0000:02:00.0: Detected 256MiB VRAM [drm] nouveau 0000:02:00.0: Stolen system memory at: 0x0070000000 [drm] nouveau 0000:02:00.0: 64 MiB GART (aperture) [drm] nouveau 0000:02:00.0: disabling HDMI functions on output VGA-1 [drm] nouveau 0000:02:00.0: disabling HDMI functions on output HDMI-A-1 [drm] nouveau 0000:02:00.0: allocated 1280x720 fb: 0x2f0000, bo f4e85c00 fbcon: nouveaufb (fb0) is primary device fb0: nouveaufb frame buffer device [drm] Initialized nouveau 0.0.16 20090420 for 0000:02:00.0 on minor 0 By the way, my TV is a Sharp Aquos LC-32DE5
Created attachment 60346 [details] [review] something to try.. This is the only thing I can think of that NVIDIA might be doing that has a chance of making your display decide to not overscan. Assuming this doesn't work, I'd be *very* interested in seeing a mmiotrace of the binary driver setting your display up so it doesn't overscan.. In my experience, the binary driver does no better than any other driver I've ever seen at avoiding this bad behaviour for crappy displays.
(In reply to comment #10) > Created attachment 60346 [details] [review] [review] > something to try.. > > This is the only thing I can think of that NVIDIA might be doing that has a > chance of making your display decide to not overscan. > > Assuming this doesn't work, I'd be *very* interested in seeing a mmiotrace of > the binary driver setting your display up so it doesn't overscan.. In my > experience, the binary driver does no better than any other driver I've ever > seen at avoiding this bad behaviour for crappy displays. The patch didn't help. I will do the mmiotrace as soon as possible. Thanks!
(In reply to comment #10) > Assuming this doesn't work, I'd be *very* interested in seeing a mmiotrace of > the binary driver setting your display up so it doesn't overscan.. In my > experience, the binary driver does no better than any other driver I've ever > seen at avoiding this bad behaviour for crappy displays. Sent the mmiotrace via private email. Please let me know if you don't receive it.
Hi again, I just noticed that the nvidia-settings program has an option to export the EDID file. Would the EDID file help in any way to fix this issue?
Still a problem with a recent kernel and other sw components (especially xrandr and xserver)?
(In reply to Tobias Klausmann from comment #14) > Still a problem with a recent kernel and other sw components (especially > xrandr and xserver)? The problem was never solved by updating the software to the latest available up to September 2013. After that, there is no way to know, since that is when I changed to a new TV that doesn't have overscan. Sorry, but I can't help anymore with this.
Thanks for providing feedback! Closing this as WONTFIX as we don't know if it _is_ still a problem and cant reproduce this. Anybody having this problem and can provide feedback for newer kernels, feel free to reopen!
I hate to revive a closed bug, but I'm having this problem too. My nVidia card is connected to though HDMI to a TV that doesn't permit overscanning to be disabled. I can compensate for it in X by setting hborder and vborder with xrandr, like in comment #1. But there's no equivalent options for the framebuffer console, so I lose the top and bottom lines of the console, and about six characters on either side. I guess this is a feature request rather than a bug: add some kind of setting to nouveaufb that allows underscan to be controlled. The ideal would be hborder and vborder settings same as xrandr uses. This would be far easier to deal with than trying to mess around with EDIDs, or expecting all TV manufacturers to add a "disable overscan" feature to their displays.
I can confirm that overscan makes a polaroid 40" tv (tla-04011c) pretty useless with nouveau. It has no option in TV menu to modify the overscan and remote is MIA but i have my doubts that they bothered to include it there either. nvidia driver has underscan option which when set to 50 brings the DE menus, etc back on screen. Kodi in fullscreen acts like it didn't get the memo but i haven't looked into addressing that yet. It would be nice if there were a command line or kernel line setting in grub for designating underscan, if that would solve the problem. I haven't tested enough with nvidia to verify it's actually universally solved. I'd much rather use nouveau. thanks for your work.
(In reply to ITwrx from comment #18) > Kodi in fullscreen acts like it didn't get the > memo but i haven't looked into addressing that yet. Here is how you fix it in Kodi: kodi-send --action='ActivateWindow(screencalibration)' But of course, fixing the overscan in the driver is the proper solution.
@lameventanas@gmail.com i ran "kodi -send --action='ActivateWindow(screencalibration)'" but it just opened up kodi in default fashion and underscan was still not accounted for. was "screencalibration" above just an example? thanks
(In reply to ITwrx from comment #20) > @lameventanas@gmail.com > > i ran "kodi -send --action='ActivateWindow(screencalibration)'" > > but it just opened up kodi in default fashion and underscan was still not > accounted for. was "screencalibration" above just an example? > > thanks You have to run this (don't insert a space): "kodi-send --action='ActivateWindow(screencalibration)'" once Kodi is already running, it will trigger the screen calibration dialog, where you can compensate for overscan/underscan by yourself (in Kodi). You can also find it somewhere in the Settings window.
-- 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/xorg/driver/xf86-video-nouveau/issues/22.
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.