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...
------------------------------------------------------------------------
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
