Bug 75246 - [Bisected] HSW unable to work on two pipes
Summary: [Bisected] HSW unable to work on two pipes
Status: CLOSED DUPLICATE of bug 75077
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: high major
Assignee: Jesse Barnes
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
: 74962 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-02-20 06:52 UTC by Qingshuai Tian
Modified: 2016-10-07 10:14 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg after boot up with two pipes (HDMI&VGA) (120.57 KB, text/plain)
2014-02-20 06:52 UTC, Qingshuai Tian
no flags Details

Description Qingshuai Tian 2014-02-20 06:52:35 UTC
Created attachment 94410 [details]
dmesg after boot up with two pipes (HDMI&VGA)

Environment:
-------------------
  Kernel: (drm-intel-next-queued) 4c0e552882114d1edb588242d45035246ab078a0

Description:
------------------------
When the desktop is booted up with HDMI and VGA connected, only the HDMI monitor lighted up normally. But when run "testdisplay -i", it showed that both VGA and HDMI are connected,and "testdisplay -a" also works well on both of them.

When plugged in HDMI or VGA separately at one time, they all work well.

This is a regression. I bisected it and it showed: 
eb1bfe807cb7b62a326fa20df5e3118a32c6f923 is the first bad commit
commit eb1bfe807cb7b62a326fa20df5e3118a32c6f923
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Feb 12 12:26:25 2014 -0800

    drm/i915: allow re-use BIOS connector config for initial fbdev config v3

    The BIOS or boot loader will generally create an initial display
    configuration for us that includes some set of active pipes and
    displays.  This routine tries to figure out which pipes and connectors
    are active and stuffs them into the crtcs and modes array given to us by
    the drm_fb_helper code.

    The overall sequence is:
      intel_fbdev_init - from driver load
        intel_fbdev_init_bios - initialize the intel_fbdev using BIOS data
        drm_fb_helper_init - build fb helper structs
        drm_fb_helper_single_add_all_connectors - more fb helper structs
      intel_fbdev_initial_config - apply the config
        drm_fb_helper_initial_config - call ->probe then register_framebuffer()
            drm_setup_crtcs - build crtc config for fbdev
              intel_fb_initial_config - find active connectors etc
            drm_fb_helper_single_fb_probe - set up fbdev
              intelfb_create - re-use or alloc fb, build out fbdev structs

    v2: use BIOS connector config unconditionally if possible (Daniel)
        check for crtc cloning and reject (Daniel)
        fix up comments (Daniel)
    v3: use command line args and preferred modes first (Ville)

    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    [danvet: Re-add the WARN_ON for a missing encoder crtc - the state
    sanitizer should take care of this. And spell-ocd the comments.]
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 dbe7ef821ba404c994fbc579461b7e0d4febf10a 1b40c56483f03c15ae495a85a78fe740beeeb0e9 M      drivers

I think this bug may be related to Bug 75077.

Test Step:
--------------------
1. connect HDMI&VGA
2. Boot up 
3. testdisplay -i 
4. testdisplay -a
Comment 1 Chris Wilson 2014-02-20 09:11:46 UTC
What is the bug here? It is just a change in default behaviour, but nothing appears to be broken.
Comment 2 Jesse Barnes 2014-02-20 20:41:30 UTC
Yeah this is just a change in behavior.  As long as we can still light up HDMI and VGA later with testdisplay, X, or whatever, there's no bug here.
Comment 3 Qingshuai Tian 2014-02-21 01:57:57 UTC
(In reply to comment #2)
> Yeah this is just a change in behavior.  As long as we can still light up
> HDMI and VGA later with testdisplay, X, or whatever, there's no bug here.

When start X, xrandr shows that HDMI and VGA are connected, while only the HDMI monitor can display the X window correctly and the VGA monitor still stays black. 

After I start gnome-session, then the monitors both can show correctly.
As all these behaviour above, shall we close this bug?
Comment 4 Chris Wilson 2014-02-21 08:46:16 UTC
Does xrandr say they are connected and enabled? If nothing tries to configure the extra pipes, they will remain off.

Please paste the output of xrandr after X starts, and after running xrandr --auto.
Comment 5 Qingshuai Tian 2014-02-24 01:55:15 UTC
(In reply to comment #4)
> Please paste the output of xrandr after X starts, and after running xrandr
> --auto.

After the system boot up with VGA and HDMI connected and X starts, the HDMI monitor can display correctly and the VGA stays black.
At this moment, the xrandr shows:
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
VGA1 connected (normal left inverted right x axis y axis)
   1680x1050     59.95 +
   1280x1024     75.02    60.02
   1280x960      60.00
   1152x864      75.00
   1024x768      75.08    70.07    60.00
   832x624       74.55
   800x600       72.19    75.00    60.32    56.25
   640x480       75.00    72.81    66.67    60.00
   720x400       70.08
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080     60.00*+  50.00    59.94
   1920x1080i    60.00    50.00    59.94
   1280x1024     75.02    60.02
   1152x864      75.00
   1280x720      60.00    50.00    59.94
   1440x576i     50.00
   1024x768      75.08    60.00
   1440x480i     60.00    59.94
   800x600       75.00    60.32
   720x576       50.00
   720x480       60.00    59.94
   640x480       75.00    60.00    59.94
   720x400       70.08
DP1 disconnected (normal left inverted right x axis y axis)
HDMI3 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Then after I run xrandr --auto,  the VGA and HDMI can both show the X window correctly.
Comment 6 Chris Wilson 2014-02-24 08:31:24 UTC
*** Bug 74962 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Vetter 2014-03-03 14:26:30 UTC

*** This bug has been marked as a duplicate of bug 75077 ***
Comment 8 Jari Tahvanainen 2016-10-07 10:14:01 UTC
Closing verified as duplicate of closed+verified.


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.