Bug 67176

Summary:

Primary output broken in zaphod mode (regression)

Product:

xorg

Reporter:

Nick Bowler <nbowler>

Component:

Driver/intel

Assignee:

Chris Wilson <chris>

Status:

RESOLVED FIXED

QA Contact:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Severity:

normal

Priority:

medium

Version:

git

Hardware:

Other

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Xorg.log from a broken session	none
Fix build error with --enable-debug=full	none
Xorg.log from driver configured with --enable-debug=full (xz compressed)	none

Description Nick Bowler 2013-07-22 14:42:39 UTC

Created attachment 82821 [details]
Xorg.log from a broken session

After upgrading xf86-video-intel to latest git, my "primary" display
(connected via HDMI) no longer works: the display simply enters standby mode
after starting X.  The display is still "there", and poking at it with xrandr
-display :0.0 shows that it is somehow configured to a nonsense mode:

  Screen 0: minimum 320 x 200, current 320 x 200, maximum 32767 x 32767
  HDMI1 connected (normal left inverted right x axis y axis)
     1920x1080      59.9 +   60.0     50.0     60.0
     1920x1080i     30.0     25.0
     1680x1050      59.9
     1280x1024      75.0     60.0
     1152x864       75.0
     1280x720       50.0     60.0
     1024x768       75.1     60.0
     832x624        74.6
     800x600        75.0     60.3     56.2
     720x576        50.0
     720x480        59.9
     640x480        75.0     60.0     59.9
     720x400        70.1

The output starts to work again after manually configuring to 1920x1080 but
pointer screen crossings are all messed up.  Bisecting pinpoints the following
commit in xf86-video-intel; reverting this commit on top of master appears to
correct the issues:

  ea508c177c961ba2f00129476a22a32ff3ea6f1b is the first bad commit
  commit ea508c177c961ba2f00129476a22a32ff3ea6f1b
  Author: Chris Wilson <chris@chris-wilson.co.uk>
  Date:   Thu Jul 4 20:19:20 2013 +0100
  
      sna: Set 1024x768 fb in absence of any connected devices
      
      No actual initial configration magic is required, all we need to do is
      set the initial framebuffer size with no connected outputs and leave it
      to the core to select CompatOutput() the like.
      
      Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
  
  :040000 040000 9ed8e6c7baee59c48687bec00e15b4d878780a9e 0c6e5509fa6a22161e8302303932f04783b486f3 M	src

Running Linux 3.9.11, xorg-server 1.14.2.

Comment 1 Chris Wilson 2013-07-22 16:43:20 UTC

Can you please compile with --enable-debug=full and attach the startup log? I need to work out why we failed to find the right connector for ZaphodHead 0 and then why we chose to use 320x200 rather than 1024x768. Thanks.

Comment 2 Nick Bowler 2013-07-22 17:40:46 UTC

Created attachment 82829 [details] [review]
Fix build error with --enable-debug=full

I had to make this change to get the driver to compile when configured
with --enable-debug=full

Comment 3 Nick Bowler 2013-07-22 17:43:23 UTC

Created attachment 82831 [details]
Xorg.log from driver configured with --enable-debug=full (xz compressed)

Comment 4 Chris Wilson 2013-07-22 18:40:23 UTC

I'm puzzled as to how we ended up with a nonsense mode, but I can at least understand how the probe function failed.

commit 3e2a1be13914e9ba13aaca06576a4f0e0f6e8fb0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Jul 22 19:34:32 2013 +0100

    sna: Bail if we fail to find the attached CRTC during probing
    
    In a Zaphod configuration, the set of CRTCs available for an output is
    limited, and if that set does not match with the already established
    linkage, our quick probe function will select no mode. However, since
    the output is already on, the user definitely would like to continue
    using it, so fallback to InitialConfiguratio to select an appropriate
    mode.
    
    Reported-by: Nick Bowler <nbowler@draconx.ca>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67176
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Comment 5 Nick Bowler 2013-07-22 20:30:13 UTC

Confirmed that the issue is solved in latest git.  Thanks!

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.