Bug 31058

Summary: Flickering area on external monitor [9400M]
Product: xorg Reporter: Felix Leimbach <felix.leimbach>
Component: Driver/nouveauAssignee: Nouveau Project <nouveau>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: hramrach
Version: git   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
screenshot of reproducable kernel OOPS because of fullscreen VLC on external monitor
none
stacktrace (netconsole) of OOPS none

Description Felix Leimbach 2010-10-22 13:09:25 UTC
On a MacBook 6,1 with linux 2.6.36 (64bit) I see two related problems on an external TFT display, connected via a displayport->DVI adapter:

1) With the TFT's native resolution of 1600x1200 the low area just flickers. The color of the flickering seems to be related to the background and other windows in that area. It's size also varies. I've filmed an instance with a relatively big size, see video [1].

2) When I use 1280x1024 instead the screen looks fine except for a very short full-screen flickering approx. every 3-4 minutes. It lasts only a fraction of a second though.

Details of my env:
- Booted from EFI (possible after Ben's work at #29171)
- xorg-server-1.9.0.902 (gentoo)
- xf86-video-nouveau from today's git
- libdrm from today's git

[1] http://dl.dropbox.com/u/10133404/flickeringarea.ogg
Comment 1 Pekka Paalanen 2010-10-22 15:23:40 UTC
This is probably an irrelevant comment, but...

You seem to have Samsung SyncMaster 204B monitor, which has two known typical faults: dying chinese electrolyte capacitors, and instability at the monitor's own recommended mode of 1600x1200 60 Hz. Your symptoms, though, do not fit either of these, but I tought you'd like to know. I have personally fixed one of these monitors.

The only fix for capacitors is replacing them. The display mode problem, however, is more interesting. The standard (and the one the monitor EDID advertises) 1600x1200 mode uses 162 MHz pixel clock, which the monitor can only barely accept. Symptoms of mode failure are image blackouts, and white or green "snowing" (fast moving random bright pixels). Severity depends on the screen contents.

The fix for the mode failure is easy: use 1600x1200 60 Hz reduced blanking mode. Its pixel clock is low enough (130-something MHz) for the monitor to be stable. That is my personal experience.

If you want to stress-test your monitor, make it show this image:
http://koti.mbnet.fi/inventor/download/kuvia/raster.gif
In the 162 MHz mode, my monitor simply refuses to show anything, or misbehaves badly. On reduced blanking mode, it works like a charm.

I would recommend the reduced blanking mode regardless if my explanation has anything to do with your actual problem. When you test different resolutions and display modes, check the monitor's on-screen display for the mode size and frequencies. I do not remember the default on Nouveau, but we may be feeding a 1600x1200 mode regardless of the resolution you have selected (GPU rescaling), even on VGA text mode(!).

Cheers.
Comment 2 Felix Leimbach 2010-10-23 10:24:05 UTC
(In reply to comment #1)
> You seem to have Samsung SyncMaster 204B monitor, which has two known typical
> faults:
> dying chinese electrolyte capacitors, and instability at the monitor's
> own recommended mode of 1600x1200 60 Hz.

(offtopic)
Yeah, had to replace 4 leaking capacitors after approx 2 years too, since then its running great again. However the same monitor works just fine with another PC and also with the nvidia binary driver.
Thanks for the hint re. ReducedBlanking, will check it out once I *can* run at the native resolution.

(back on topic)
Today I've found a reproducable kernel panic related to the external display  might be related:

When I play a video in VLC on the external Monitor the kernel panics as soon as I switch to fullscreen. Maximized window works.

I'll attach a screenshot of the OOPs.
Comment 3 Felix Leimbach 2010-10-23 10:37:30 UTC
Created attachment 39654 [details]
screenshot of reproducable kernel OOPS because of fullscreen VLC on external monitor
Comment 4 Marcin Slusarz 2010-10-23 15:54:52 UTC
We are hitting BUG_ON in drm_vblank_put, but the stacktrace from your oops does not make any sense. Please recompile your kernel with CONFIG_DEBUG_INFO, reproduce this bug and attach new oops. If it's possible catch it with netconsole (see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/networking/netconsole.txt;hb=HEAD )
Comment 5 Felix Leimbach 2010-10-24 01:10:34 UTC
Created attachment 39662 [details]
stacktrace (netconsole) of OOPS

Stacktrace as requested in comment #4.
Note that every line was logged twice, due to me exerimenting with netconsole targets. Please just ignore that.
Comment 6 Felix Leimbach 2010-10-24 01:21:49 UTC
New finding: The OOPS disappears if I disable VLC's option "Accelerated video output (Overlay)".
Note that on the laptop's internal screen I *can* play full screen with that option *enabled* and no OOPS happens. It only happens on the external display.
Comment 7 Felix Leimbach 2010-10-24 01:29:20 UTC
I've split off bug #31074 which is about that OOPS triggered by VLC.
This bug is about the original problem of a flickering area on the external screen.
Comment 8 Ilia Mirkin 2013-08-19 16:40:51 UTC
It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one.

Thanks,

The Nouveau Team

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.