From: ykzhao <yakui.zhao@intel.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: "intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [Intel-gfx] [PATCH 3/4] drm/i915: use ACPI LID status for LVDS ->detect hook
Date: Fri, 17 Jul 2009 09:44:11 +0800 [thread overview]
Message-ID: <1247795051.4113.76.camel@localhost.localdomain> (raw)
In-Reply-To: <20090716093217.431e733b@jbarnes-g45>
On Fri, 2009-07-17 at 00:32 +0800, Jesse Barnes wrote:
> On Thu, 16 Jul 2009 09:54:44 +0800
> ykzhao <yakui.zhao@intel.com> wrote:
>
> > On Thu, 2009-07-16 at 06:11 +0800, Jesse Barnes wrote:
> > > We can't load or hotplug detect LVDS like we can other outputs, but
> > > if there's a lid device present we can use it as a proxy. This
> > > allows the LFP state to be determined at ->detect time, making
> > > configurations requiring manual intervention today "just work"
> > > assuming the lid device status is correct.
> > It is ok that the LID status is to decide whether the LVDS is
> > connected/disconnected.
> >
> > But on some boxes the initial LID status is incorrect. It reports that
> > LID is closed although it is open.
> > For example:
> > http://bugzilla.kernel.org/show_bug.cgi?id=5809
> > http://bugzilla.kernel.org/show_bug.cgi?id=13263
> > http://bugzilla.kernel.org/show_bug.cgi?id=5904
> > https://bugs.launchpad.net/ubuntu/+bug/34389
> > Maybe this feature is not supported on the above laptops. That means
> > that LVDS is always connected regardless of LID status.
> >
> > At the same time on some boxes there is no ACPI LID event when the LID
> > is reopened. In such case we can't send the hotplug event to user
> > space when the LID is reopened. How about disable this feature on
> > such box? For example: Aspire One.
> >
> >
> > I have another issue about the hotplug event.
> > On some boxes it will continue to report the LID event when the LID
> > is closed. In such case we had better not send the hotplug event to
> > user space. Otherwise the user space will receive too many hotplug
> > event about LVDS. For example:
> > http://bugzilla.kernel.org/show_bug.cgi?id=10485
> > http://bugzilla.kernel.org/show_bug.cgi?id=5853
> >
> > So it will be better that the feature of hotplug/LID status is not
> > supported on such boxes.
>
> Yeah those are all good points; thanks for the list of bugs. Any
> suggestions on how to do a blacklist? Is there an ACPI or DMI
> identifier we could use?
How about not register the lid notifier callback function for the boxes
that fall into the backlist?
And the LVDS detection will always return connected when there is no LID
notifier callback.
Sorry that there is no dmidecode for the above laptops. I will ask the
bug reporter to attach them.
Thanks.
Yakui
>
next prev parent reply other threads:[~2009-07-17 1:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-15 22:11 drm/i915: LVDS lid patches Jesse Barnes
2009-07-15 22:11 ` [PATCH 1/4] ACPI button: provide lid status functions Jesse Barnes
2009-07-15 22:48 ` Matthew Garrett
2009-07-15 22:54 ` Jesse Barnes
2009-07-16 1:16 ` [Intel-gfx] " ykzhao
2009-07-15 22:11 ` [PATCH 2/4] drm/i915: force mode set at lid open time Jesse Barnes
2009-07-15 22:54 ` Matthew Garrett
2009-07-16 1:36 ` [Intel-gfx] " ykzhao
2009-07-16 16:30 ` Jesse Barnes
2009-07-17 1:34 ` ykzhao
2009-07-17 16:33 ` Jesse Barnes
2009-07-15 22:11 ` [PATCH 3/4] drm/i915: use ACPI LID status for LVDS ->detect hook Jesse Barnes
2009-07-15 22:55 ` Matthew Garrett
2009-07-15 23:09 ` Jesse Barnes
2009-07-16 1:54 ` [Intel-gfx] " ykzhao
2009-07-16 16:32 ` Jesse Barnes
2009-07-17 1:44 ` ykzhao [this message]
2009-07-15 22:11 ` [PATCH 4/4] drm/i915: generate a KMS uevent at lid open/close time Jesse Barnes
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=1247795051.4113.76.camel@localhost.localdomain \
--to=yakui.zhao@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-acpi@vger.kernel.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