On Thu, 11 Jun 2009 15:16:27 +0800 yakui_zhao <yakui.zhao@xxxxxxxxx> wrote: > On Wed, 2009-05-27 at 16:58 +0800, Jesse Barnes wrote: > > > > > > > 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. > Hi, > It is a good point that the LID status is used to decide whether > the LVDS is connected or not. > As Rui said in the previous thread, sometimes the initial status > of LID is incorrect on some laptops. If we expect that LVDS can be > initialized correctly on such boxes, we will have to add the quirk so > that the LID status is not used for LVDS detection. > But maybe on such boxes the LID initial status is correct after > BIOS upgrading or using custom DSDT. Do we need to delete the quirk > for such box? It is difficult to manage. > > So IMO we had better not use the LID status to determine whether > the LVDS is connected or not. Well, what should we use then? Think of a common use case: you plug in an external monitor and shut your lid. Do we want to make the user manually change their configuration? Or detect that the lid is no longer in use? And what about the case where they boot with the lid closed (e.g. in a docked scenario)? We want to support that automatically too... If we can solve these issues some other way, that's fine, but right now we have nothing; I think my patch is an improvement over that, even if it won't work everywhere w/o quirks. Len or Matthew, any comments? -- 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
