All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Heider <andreas@meetr.de>
To: intel-gfx@lists.freedesktop.org
Subject: Graphics switching and LVDS detection
Date: Wed, 14 Mar 2012 19:22:27 +0100	[thread overview]
Message-ID: <1331749347.7113.46.camel@umbp> (raw)

Hello everyone,

I'm working on graphics switching for Apple Macbook Pros and still have
a few unresolved issues connected to the i915 driver and would be happy
if someone could help me with a few hints how to solve them in a clean
way.

Switching works by just switching the display lines with a mux (There
are three connections that can be switched individually, DDC, internal
display, external display). At boot the dedicated card (nvidia, I'm
using nouveau) is connected to everything. 

The intel card is a: "00:02.0 VGA compatible controller: Intel
Corporation Core Processor Integrated Graphics Controller (rev 12)", and
the laptop display is connected via LVDS.

The main problem is that during boot there is nothing connected to the
intel card, and there is no vbios/VBT so it shuts down LVDS.

Vga_switcheroo switcheroo provides a callback "reprobe" for this
situation, which tells the video driver that the mux was switched and it
should look for new displays. I implemented support for it analogously
to how it is implemented in nouveau, you can find the patch here:
http://andreas.meetr.de/intel/0001-Add-support-for-vga_switcheroo-reprobe.patch

With this patch switching works fine with external displays connected
via DP, but the internal display is black as the LVDS output is
disabled.

It's possible to manually switch the mux in grub so the intel card is
connected during boot, in which case the internal display works fine.
But due to other reasons (flickering and black display during boot,
messed up mux state) this is only useful as a temporary hack. But it
shows that the problem is indeed the display not being connected.

At the moment I'm just forcing the LVDS connector on, which kind of
works. The text console is broken after a switch (panel fades to white)
which is not surprising, but X runs fine. My current changes are at
http://andreas.meetr.de/intel/force_lvds.patch Please note that this by
far isn't finished yet but I figured it's better to include it in this
mail instead of just describing it.

You can find dmesg output with drm.debug=0x14 here:
http://andreas.meetr.de/intel/dmesg.intel.white (intel disconnected at
boot, broken white text console)
http://andreas.meetr.de/intel/dmesg.intel.switch (intel connected at
boot, working text console)

Search for "i915: reprobe" to get to the interesting part. I'm
especially wondering why it doesn't like the edid mode: 

[   23.007673] [drm:drm_mode_debug_printmodeline], Modeline
26:"1680x1050" 0 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x48 0xa
[   23.007680] [drm:drm_mode_prune_invalid], Not using 1680x1050 mode 12

How could this be implemented in a clean way? Of course forcing LVDS on
should become a parameter, but i'm not sure how to handle initially not
having any idea what the mode should be and then adapting to the new
mode after reprobe.

Is there a way to change the mode of the framebuffer console upon
reprobe?

Thanks,
Andreas

P.s.: When I boot with the display connected to the intel card and
switch to nouveau, I at least get a usable fbcon at a lower resolution.
I'm not sure why that is the case, but I guess it's due to information
from the vbios or because the nvidia card was already used in grub.

P.p.s: I don't think there is any vbios information available for the
intel card at all.

             reply	other threads:[~2012-03-14 18:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-14 18:22 Andreas Heider [this message]
2012-03-16 20:32 ` Graphics switching and LVDS detection Oliver Seitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1331749347.7113.46.camel@umbp \
    --to=andreas@meetr.de \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.