| Summary: | Need one kernel option to enable all connected displays | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Guang Yang <guang.a.yang> | ||||
| Component: | DRM/Intel | Assignee: | Daniel Vetter <daniel> | ||||
| Status: | CLOSED INVALID | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Severity: | enhancement | ||||||
| Priority: | lowest | CC: | intel-gfx-bugs, lei.a.liu, qingshuai.tian, ville.syrjala | ||||
| Version: | unspecified | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
|
Description
Guang Yang
2014-02-27 01:22:03 UTC
Why? (In reply to comment #1) > Why? This new changing will cause inconvenient for QA's work :). After talking with Jesse at meeting, he agree to add one new option for kernel for QA. Just report this bug to track this task. i915.fastboot=-1? (In reply to comment #3) > i915.fastboot=-1? It's a different issue, disabling fastboot just kills the modeset hacks, not the initial config takeover. I guess we need to be a notch more clever and also light up any displays not lit up by the bios (but otherwise keep the crtc/output/modes as set). Assigning to Jesse to polish this more. i.e. expect me to shot down a patch just adding the option ;-) Consolidating these bugs a bit *** This bug has been marked as a duplicate of bug 75077 *** > i.e. expect me to shot down a patch just adding the option ;-)
All QA is asking for is a way to go back to the old behavior, which
should be pretty trivial.
What is it you're threatening to shoot down so I don't bother posting
it?
On Mon, Mar 3, 2014 at 6:12 PM, <bugzilla-daemon@freedesktop.org> wrote: > --- Comment #7 from Jesse Barnes <jbarnes@virtuousgeek.org> --- >> i.e. expect me to shot down a patch just adding the option ;-) > > All QA is asking for is a way to go back to the old behavior, which > should be pretty trivial. > > What is it you're threatening to shoot down so I don't bother posting > it? I think we should actually enable any outputs the bios didn't, while still keeping the bios' config wrt pipe selections and precise mode. At least I think that's the least suprising thing to do, and for almost all fastboot use-cases we don't care one bit about multihead. This one isn't a dupe, it's a feature request to allow going back to something like the old behavior, lighting up as many displays as possible. *** Bug 75077 has been marked as a duplicate of this bug. *** Note to QA: you still can't use this behavior as a reliable test of whether a given port is working. That's because we can't support all possible 3 output configs on all platforms. Sometimes displays won't be enabled, but that doesn't mean there's a bug. Created attachment 95113 [details] [review] fallback to old initial config if not all outputs are enabled Please test. Ville, can you please also give this patch a spin to check whether it does what you expect? (In reply to comment #13) > Ville, can you please also give this patch a spin to check whether it does > what you expect? Needs a small adjustment and then it works on my IVB machine at least. diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index afccc6e..4f1a977 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -318,8 +318,6 @@ static bool intel_fb_initial_config(struct drm_fb_helper *fb_helper, continue; } - num_connectors_enabled++; - encoder = connector->encoder; if (!encoder || WARN_ON(!encoder->crtc)) { DRM_DEBUG_KMS("connector %d has no encoder or crtc, skipping\n", @@ -328,6 +326,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper *fb_helper, continue; } + num_connectors_enabled++; + new_crtc = intel_fb_helper_crtc(fb_helper, encoder->crtc); Guang, please apply Ville's fixup on top of my patch when testing - my patch alone is broken. (In reply to comment #4) > (In reply to comment #3) > > i915.fastboot=-1? > > It's a different issue, disabling fastboot just kills the modeset hacks, not > the initial config takeover. I guess we need to be a notch more clever and > also light up any displays not lit up by the bios (but otherwise keep the > crtc/output/modes as set). Assigning to Jesse to polish this more. What I meant is that this QA mode is the antithesis of fastboot - and I want to avoid the mistake of them declaring fastboot a failure because of their own requirements. I found that with Daniel's patch(03494932b88b57cb4a177f754bb0c87bf342d1b8) on dinq which including the patch on comment 12 and 14 can enable all connectd outputs as our driver did before, did this patch impact the fastboot hardly as Chris worried? I think we've fixed the original issues that prevented hotplug on the fbcon from working correctly, so I think there's no need any more for additional hacks. Yeah, agree with Daniel, close this one. Closing verified+invalid. |
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.