On Tue, Jun 16, 2009 at 8:33 PM, Jesse Barnes<jbarnes@xxxxxxxxxxxxxxxx> wrote: > 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... Just another use case for this patch : Michael Ringe recently sended me a patch to handle backlight power in eeepc-laptop. > There is another minor problem I could not solve. When the lid is closed, the > status of the backlight device driver is not updated, so reading from > /sys/class/backlight/eeepc/bl_power still yields 0 (=power on). Or, if you > switch off the backlight and then close and reopen the lid, the backlight is on, > but the driver still thinks it's off. If you reboot in this status, the notebook > will come up with the backlight switched off, and you have to press Fn-F7 to > switch it on. > To solve this problem, eeepc-laptop would need to register a notification handler > with \_SB.LIB. But this is not possible because a handler is already registered by > the acpi button driver. Maybe there is a way too register a handler with the button driver? We ended up with an input handler, checking on SW_LID, but it's not very clean, and I'd better use your patch. -- Corentin Chary http://xf.iksaif.net - http://uffs.org -- 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
