Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lukas <christoph.lukas@gmx.net>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: External display
Date: Sun, 16 Jan 2011 09:13:44 +0100	[thread overview]
Message-ID: <1295165624.2596.3.camel@hoss.staad.pingworks.net> (raw)
In-Reply-To: <849307$b585ru@azsmga001.ch.intel.com>

Hi Chris,

> > 
> > I am using a Dell E6410 notebook running Ubuntu. Most of the time I am
> > running this notebook in a docking station with closed lid and with an
> > external (DVI) monitor attached to the dock.
> > 
> > Running different kernels I see different behaviour regarding the
> > display configuration after boot.
> > 
> > Booting a 2.6.32 based kernel the internal display is turned off, the
> > external display is turned on and running at it's native resolution of
> > 1920x1200. 
> > This is what I would expect.
> 
> Once upon a time we trusted the lid status and reported the internal
> screen as disconnected when the lid was closed. We were beset by bugs
> reporting broken lid status and the LVDS not working. So we gave up.
> Usually between the BIOS and userspace responding to lid notification
> events, the LVDS is turned off when the lid is closed.
> 
> See commit 6e6c822868f113dabe3c33bdd91e883cc28fa11b
> Author: Eric Anholt <eric@anholt.net>
> Date:   Wed Mar 17 13:48:06 2010 -0700
> 
>     drm/i915: Stop trying to use ACPI lid status to determine LVDS connection.
>     
>     I've been getting more and more quirk reports about this.  It seems
>     clear at this point that other OSes are not using this for determining
>     whether the integrated panel should be turned on, and it is not
>     reliable for doing so.  Better to light up an unintended panel than to
>     not light up the only usable output on the system.
>     
>     Signed-off-by: Eric Anholt <eric@anholt.net>
>     Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> You may want to try:
> 
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds
> index 9795eb5..45b1fe4 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -474,11 +474,9 @@ intel_lvds_detect(struct drm_connector *connector, bool for
>         struct drm_device *dev = connector->dev;
>         enum drm_connector_status status = connector_status_connected;
>  
> -       /* ACPI lid methods were generally unreliable in this generation, so
> -        * don't even bother.
> -        */
> -       if (IS_GEN2(dev) || IS_GEN3(dev))
> -               return connector_status_connected;
> +       /* ACPI lid methods were generally unreliable, so don't even bother. */
> +       if (INTEL_INFO(dev)->gen >= 5 && !acpi_lid_open())
> +               status = connector_status_disconnected;
>  
>         return status;
>  }
> 

thanks for your response and patch. But this patch did not change
anything for me, sorry. The internal display is still turned on when
booting with closed lid.

I would guess this function is only called for lvds displays while the
internal display on the Dell E6410 is an eDP?

I have added a printk just before the conditional and I have never seen
the output in dmesg.



I would not bother too much about using gnome-display-properties (or
xrandr) to turn the internal display off once after login. What I think
is a little bit annouying is that the internal display is turned back on
after each DPMS blanking.


Thanks and Regards,
Christoph

      parent reply	other threads:[~2011-01-16  8:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-14 12:38 External display Christoph Lukas
2011-01-14 12:51 ` Chris Wilson
2011-01-14 13:57   ` Ivan Bulatovic
2011-01-14 17:58     ` Damnshock
2011-01-16 16:31       ` Damnshock
2011-01-16 17:14         ` Ivan Bulatovic
2011-01-16 17:27           ` Damnshock
2011-01-16 18:01             ` Ivan Bulatovic
2011-01-14 18:57     ` Christoph Lukas
2011-01-16  8:13   ` Christoph Lukas [this message]

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=1295165624.2596.3.camel@hoss.staad.pingworks.net \
    --to=christoph.lukas@gmx.net \
    --cc=chris@chris-wilson.co.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox