Re: [Intel-gfx] [RFC] i915/acpi: add lid status notification and detection

[Fu Michael <michael_fu@linux.intel.com>]

Jesse Barnes wrote:
> On Fri, 22 May 2009 09:22:31 +0800
> Fu Michael <michael_fu@linux.intel.com> wrote:
>
>   
>> Jesse Barnes wrote:
>>     
>>> On Thu, 21 May 2009 16:57:53 +0800
>>> Zhang Rui <rui.zhang@intel.com> 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
>
>