Jesse Barnes wrote:
On Fri, 22 May 2009 09:22:31 +0800
Fu Michael <michael_fu@xxxxxxxxxxxxxxx> wrote:
Jesse Barnes wrote:
On Thu, 21 May 2009 16:57:53 +0800
Zhang Rui <rui.zhang@xxxxxxxxx> wrote:
On Wed, 2009-05-20 at 01:15 +0800, Matthew Garrett wrote:
There's also a policy question here. On some machines, a lid
close will cause the ACPI firmware to program the GPU,
disabling the pipe associated with the panel. Should we detect
this and turn it back on at open time? That could be dangerous
if userspace has received the LVDS hotplug event and changed
the config out from under us...
Comments?
It seems that the LID status is used to determine whether the
LVDS is connected.
It is not reliable. On some boxes the initial LID status is
incorrect. Maybe the LID status is open. But the ACPI returns
that the LID is close. In such case the LVDS is not initialized
and user can't get the output.
Really? I haven't seen any cases of this. They'll fail in all
sorts of fun ways with modern userland.
This is rare, and if this happens, a bug should be filed against
ACPI. BTW: we have fixed/root caused all such kind of bugs that
have been reported.
So I think it makes sense to trust the Lid state reported by ACPI
button driver.
So is that two acks for the patch? If so, should it be split or
can it just go in through the i915 driver tree?
Len? (Patch attached for reference.)
Thanks,
Jesse, Just talked with Rui, the above status is based on "BIOS
upgrade or FW fix is acceptable as a bug fix solution". are you ok
with this? :) Many lid status has to be fixed via action such as DSDT
upgrade...
Yeah, I think that's ok, even if we need quirks for some platforms. I
really hate relying on BIOS vendors/OEMs to provide BIOS updates in
general: if Windows works on a given platform, why should Linux
require a BIOS "fix" on it? In this case though, we can work around
broken platforms by just returning "open" all the time, if it comes to
that.
I'm not sure if acpi module has this kind of quirk for lid detection, if
we prepare to take this way, we'd better to quirk from our driver
directly...
Jesse
--
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
