Hi, > From: Bastien Nocera [mailto:hadess@xxxxxxxxxx] > Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control > method lid device restrictions > > On Mon, 2016-07-11 at 03:20 +0000, Zheng, Lv wrote: > > > <snip> > > > This worries me as there is no plan after "During the period the > > > userspace hasn't been switched to use the new event". > > > > > > I really hope you'll keep sending SW_LID for reliable LID > > > platforms, > > > and not remove it entirely as you will break platforms. > > > > [Lv Zheng] > > We won't remove SW_LID from the kernel :). > > > > And we haven't removed SW_LID from the acpi button driver. > > We'll just stop sending "initial lid state" from acpi button driver, > > i.e., the behavior carried out by "button.lid_init_state=ignore". > > > > Maybe it is not sufficient, after the userspace has been changed to > > support the new event, we should stop sending SW_LID from acpi button > > driver. > > For the affected devices? Sure, but I don't think that's a reasonable > thing to do for "all" the devices. We have a majority of laptops where > this isn't a problem, and it's not even a problem any more on one of > the devices that triggered this discussion (there's a patch for make > the LID status match reality for the Surface 3). [Lv Zheng] It looks, even with this fixed, there are tables never generating "lid open" event. Thus the lid notification is definitely not a "switch event". Thanks and best regards -Lv ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
