Bug 108615 - [NVE7] changing resolution causes blank screen
Summary: [NVE7] changing resolution causes blank screen
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 7.7 (2012.06)
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Nouveau Project
QA Contact: Xorg Project Team
Keywords: regression
Depends on:
Reported: 2018-10-31 20:28 UTC by jbytecoder
Modified: 2019-12-04 09:46 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

Xorg server log just after resolution switch (41.91 KB, text/x-log)
2018-10-31 20:28 UTC, jbytecoder
no flags Details
Kernel log just after the issue (245.87 KB, text/plain)
2018-10-31 20:29 UTC, jbytecoder
no flags Details
Video bios of the faulty card (91.50 KB, application/octet-stream)
2018-10-31 20:30 UTC, jbytecoder
no flags Details
View of display artifacts with mouse pointer. (3.37 MB, image/jpeg)
2018-11-21 19:10 UTC, Phil Turmel
no flags Details
View of X's complete framebuffer (triple head) screenshotted with artifacts visible (1.75 MB, image/png)
2018-11-21 19:13 UTC, Phil Turmel
no flags Details
Kernel log including a disable/re-enable cycle (87.14 KB, text/plain)
2018-11-21 19:15 UTC, Phil Turmel
no flags Details
Kernel log with a switch from native to lower resolution (915.77 KB, text/x-log)
2019-09-26 18:44 UTC, Maris Nartiss
no flags Details

Description jbytecoder 2018-10-31 20:28:21 UTC
Created attachment 142308 [details]
Xorg server log just after resolution switch

Using latest software ( linux-4.19.0, xf86-video-nouveau-1.0.15, mesa-18.2.3, libdrm-2.4.96, xorg-server-1.20.3 ). When I try to change screen resolution using xrandr to anything below native resolution the screen goes blank. To be exact 
issuing xrandr -s 1024x768 causes the flowing:
1) screen turns completely black right away
2) after some time  ( no more that 500ms ), the screen changes to black with backlight on. Looks a lot like no modesetting console without any content 
3) this situation persists, indefinitely

What is interesting is that switching to console works. The console just works. However when I switch back to X, the above procedure repeats with one detail - for a brief moment ( at the same moment as step 1) ) the content of desktop in selected resolution is visible. It seems that the desktop content is somewhere in memory but the driver decides to render some other area of memory

The only resolution to this problem that is working is to use older kernel, linux-4.9.95 to be precise  

I discovered the issue, playing games through wine. But to isolate the cause I gathered dmesg & xorg.log, running only an openbox and using xrandr to cause the issue

I don't know what further info could be usefull
Comment 1 jbytecoder 2018-10-31 20:29:34 UTC
Created attachment 142309 [details]
Kernel log just after the issue
Comment 2 jbytecoder 2018-10-31 20:30:36 UTC
Created attachment 142310 [details]
Video bios of the faulty card
Comment 3 Phil Turmel 2018-11-21 19:08:42 UTC
I have what is likely a related problem -- any change to resolution or re-enabling an output on my system, via xrandr or the equivalent KDE dialog, yields a black screen and/or artifacts from the framebuffer console.  When multiple monitors are enabled, the affected outputs are black until the mouse pointer moves in their region, yielding artifacts plus *correct* mouse pointer.

Until recently, operation was restored solely by restarting X.  With kernel 4.19.3, operation can be restored by switching to a text console (all connected outputs turn on) and switching back to X.  The phenomenon occurs on all monitor ports, on the dock or not, whether docked or not, and both before and after suspend/resume.

Laptop is an HP ZBook 17 with GK107GLM (K1100M) with gentoo unstable:

Linux corvus 4.19.3 #305 SMP PREEMPT Wed Nov 21 12:21:12 EST 2018 x86_64 Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz GenuineIntel GNU/Linux

Comment 4 Phil Turmel 2018-11-21 19:10:51 UTC
Created attachment 142552 [details]
View of display artifacts with mouse pointer.
Comment 5 Phil Turmel 2018-11-21 19:13:28 UTC
Created attachment 142553 [details]
View of X's complete framebuffer (triple head) screenshotted with artifacts visible

Note the mouse cursor on the right-hand monitor that had been disabled then re-enabled.
Comment 6 Phil Turmel 2018-11-21 19:15:41 UTC
Created attachment 142554 [details]
Kernel log including a disable/re-enable cycle

Note that no events appeared in dmesg during the xrandr changes.
Comment 7 jbytecoder 2019-09-21 20:49:48 UTC
I have tested the issue against linux-5.3 and it stil persists. I also attempted to narrow down the commit that did introduce the problem. 

Using kernel sources at https://github.com/torvalds/linux.git i detected that between tags v4.9 and v4.10  The kernel breaks @ 9439b3710df6 - this is a big change commit that intorduces drm changes planned for linux-4.10. 

I guess the issue has to do with "atomic modesseting" it would appear that for nv50 the atomic modesseting works only for default resolution, but not for any other

Can someone suggest any way to further narrow down the culprit ?
logging has no effect ( no errors appear in log )
Comment 8 Maris Nartiss 2019-09-26 18:44:29 UTC
Created attachment 145527 [details]
Kernel log with a switch from native to lower resolution

Phil Turmel – I am not certain if your issue is the same as the reporter has.
I do have exactly same symptoms – after changing resolution to not native, I get black screen with backlight on. It is not an DE or WM issue, as I was testing with bare xinit session. If there are other outputs active, they still show picture just fine (split screen or clone mode). Thus, as jbytecoder wrote, X is still fine, just nothing goes to particular output device.

G98M (NV50 family) card tested with kernel 5.0 and 5.3.

Attached dmesg was generated after a reboot, stopping sddm, starting xinit session and changing resolution to 1024x768 (native is 1440x900).
Comment 9 Martin Peres 2019-12-04 09:46:41 UTC
-- 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/464.

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.