Bug 77768

What would be useful here is drm.debug=6 dmesg from across resume, and if possible a Xorg.0.log with --enable-debug=full.

Created attachment 97797 [details]
dmesg of test run

Created attachment 97798 [details]
First start of Xorg, suspend, resume, terminate

Created attachment 97799 [details]
2nd start of X, this time kernel bug is visible

(In reply to comment #1)
> What would be useful here is drm.debug=6 dmesg from across resume, and if
> possible a Xorg.0.log with --enable-debug=full.

ok, you asked for it ;-)

kernel: 3.15-rc2+ (4d0fa8a0f01272d4de33704f20303dcecdb55df1) with yesterdays patch that fixes bug 77767

Xorg: from git, about a week old

cu,
 Knut

After the resume, the CRTC has a mode (1280x1024) but no output is connected to it (reported through GETCONNECTOR). X decides that everything is disconnected so switches off the spurious CRTC, sets up a fake 1024x768 fb and leaves kwin to decide how to enable the outputs (and kwin doesn't handle a screen resize very well...).

The root cause then is that the kernel bookkeeping is slightly off after resume, in particular the connector->status.

Try:

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 3225d51..e8fdc79 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -2777,7 +2777,7 @@ sna_output_init(ScrnInfoPtr scrn, struct sna_mode *mode, int num)
 
        /* stash the active CRTC id for our probe function */
        output->crtc = NULL;
-       if (compat_conn.conn.connection == DRM_MODE_CONNECTED)
+       if (compat_conn.conn.connection != DRM_MODE_DISCONNECTED)
                output->crtc = (void *)(uintptr_t)enc.crtc_id;

That patch masks the bug. But it still is a _kernel_ bug and not a bug of the xorg driver code. Wouldn't it be a better idea to fix the root cause?

I wonder if only my special hardware is affected. I assume that this is not the case ...

(In reply to comment #7)
> Try:
> 
> diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
> index 3225d51..e8fdc79 100644
> --- a/src/sna/sna_display.c
> +++ b/src/sna/sna_display.c
> @@ -2777,7 +2777,7 @@ sna_output_init(ScrnInfoPtr scrn, struct sna_mode
> *mode, int num)
>  
>         /* stash the active CRTC id for our probe function */
>         output->crtc = NULL;
> -       if (compat_conn.conn.connection == DRM_MODE_CONNECTED)
> +       if (compat_conn.conn.connection != DRM_MODE_DISCONNECTED)
>                 output->crtc = (void *)(uintptr_t)enc.crtc_id;

(In reply to comment #8)
> That patch masks the bug. But it still is a _kernel_ bug and not a bug of
> the xorg driver code. Wouldn't it be a better idea to fix the root cause?
> 
> I wonder if only my special hardware is affected. I assume that this is not
> the case ...

This really is a userspace bug imo - if we declare this a kernel bug we _must_ force a full detect cycle after suspend before userspace wakes up, which: a) isn't how this stuff is supposed to work really b) pessimizes everyone else for the sake of a few funky setups.

I know that upstream linux kernel has a hard "no regressions" rule, but occasionally we need to bend this a bit.

Closing this since Chris patched the ddx, thanks a lot for your bug report.

commit aec3cbb1aba8bae5537534754ea57d21896d591b                                 
Author: Chris Wilson <chris@chris-wilson.co.uk>                                 
Date:   Wed Apr 23 09:17:22 2014 +0100                                          
                                                                                
    sna: Reuse any output not explicitly disconnected

Mark as regression for stats