| Bug ID | 108615 |
|---|---|
| Summary | [NVE7] changing resolution causes blank screen |
| Product | xorg |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Driver/nouveau |
| Assignee | nouveau@lists.freedesktop.org |
| Reporter | jbytecoder@gmail.com |
| QA Contact | xorg-team@lists.x.org |
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=20
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=20
3) this situation persists, indefinitely
What is interesting is that switching to console works. The console just wo=
rks.
However when I switch back to X, the above procedure repeats with one detai=
l -
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 somewh=
ere
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=20=20
I discovered the issue, playing games through wine. But to isolate the caus=
e 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
Created attachme=
nt 142309 [details]
Kernel log just after the issue
Created attachment=
142310 [details]
Video bios of the faulty card
I have what is likely a related problem -- any change to resol= ution 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 mou= se pointer moves in their region, yielding artifacts plus *correct* mouse poin= ter. 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 conne= cted outputs turn on) and switching back to X. The phenomenon occurs on all mon= itor 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 x11-base/xorg-server-1.20.3 x11-drivers/xf86-video-nouveau-1.0.15-r1 media-libs/mesa-18.3.0_rc3 x11-libs/libdrm-2.4.96
Created attachment 142552 [details]=
View of display artifacts with mouse pointer.
| What | Removed | Added |
|---|---|---|
| CC | philip@turmel.org |
Created attachment 142553 [detai=
ls]
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.
Created attachment 142554 [detail=
s]
Kernel log including a disable/re-enable cycle
Note that no events appeared in dmesg during the xrandr changes.
| What | Removed | Added |
|---|---|---|
| Keywords | regression |
| What | Removed | Added |
|---|---|---|
| Priority | medium | high |
| Version | unspecified | 7.7 (2012.06) |
| Severity | normal | major |
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.=20 Using kernel sources at h= ttps://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.=20 I guess the issue has to do with "atomic modesseting" it would ap= pear 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 )
| What | Removed | Added |
|---|---|---|
| CC | maris.nartiss@gmail.com |
Created attachment 145527 [details]
Kernel log with a switch from native to lower resolution
Phil Turmel =E2=80=93 I am not certain if your issue is the same as the rep=
orter has.
I do have exactly same symptoms =E2=80=93 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 st=
ill
show picture just fine (split screen or clone mode). Thus, as jbytecoder wr=
ote,
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).
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | NEW | RESOLVED |
-- 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/iss= ues/464.