On Thu, 16 Jul 2009 09:54:44 +0800 ykzhao <yakui.zhao@xxxxxxxxx> 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? -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
