| Message ID | 20170510161240.13229-3-benjamin.tissoires@redhat.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Delegated to: | Rafael Wysocki |
| Headers | show |
Hi, > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > > Even if the method implementation can be buggy on some platform, > the "open" choice is worse. It breaks docking stations basically > and there is no way to have a user-space hwdb to fix that. > > On the contrary, it's rather easy in user-space to have a hwdb > with the problematic platforms. Then, libinput (1.7.0+) can fix > the state of the LID switch for us: you need to set the udev > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. > > When libinput detects internal keyboard events, it will > overwrite the state of the switch to open, making it reliable > again. Given that logind only checks the LID switch value after > a timeout, we can assume the user will use the internal keyboard > before this timeout expires. > > For example, such a hwdb entry is: > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open For the reason mentioned previously and proofs here (see patch descriptions): https://patchwork.kernel.org/patch/9717111/ We shouldn't do this. Thanks and best regards Lv > > Link: https://bugzilla.gnome.org/show_bug.cgi?id=782380 > Cc: stable@vger.kernel.org > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> > --- > drivers/acpi/button.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c > index 6d5a8c1..e19f530 100644 > --- a/drivers/acpi/button.c > +++ b/drivers/acpi/button.c > @@ -113,7 +113,7 @@ struct acpi_button { > > static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier); > static struct acpi_device *lid_device; > -static u8 lid_init_state = ACPI_BUTTON_LID_INIT_OPEN; > +static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD; > > static unsigned long lid_report_interval __read_mostly = 500; > module_param(lid_report_interval, ulong, 0644); > -- > 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On May 11 2017 or thereabouts, Zheng, Lv wrote: > Hi, > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > > > > Even if the method implementation can be buggy on some platform, > > the "open" choice is worse. It breaks docking stations basically > > and there is no way to have a user-space hwdb to fix that. > > > > On the contrary, it's rather easy in user-space to have a hwdb > > with the problematic platforms. Then, libinput (1.7.0+) can fix > > the state of the LID switch for us: you need to set the udev > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. > > > > When libinput detects internal keyboard events, it will > > overwrite the state of the switch to open, making it reliable > > again. Given that logind only checks the LID switch value after > > a timeout, we can assume the user will use the internal keyboard > > before this timeout expires. > > > > For example, such a hwdb entry is: > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > > For the reason mentioned previously and proofs here (see patch descriptions): > https://patchwork.kernel.org/patch/9717111/ I am not sure you can call this proofs. The "close" state is IMO the exact same as the "method" one, it's just that the intel driver triggers the evaluation of the _LID method, not acpi/button.c. And remember that this new default prevents userspace to fix it because it's rather easy to detect that the device is actually opened (input events coming from interanl keyboard, touchscreen, or touchpad), while reporting the lid switch as open means we can't know if the user is simply not using the internal devices, or if we have just a wrong state. Given that this patch breaks all Lenovos with a dock (I can guess that 6 lines this year are using docks, and within each line you have 2-5 variants), I'd suggest we do not break those existing laptops and just revert this patch. I would think other OEMs have a docking station with an actual power button but I can't be sure by looking at the product pages. > We shouldn't do this. I strongly disagree. I am fine if you don't want to have a blacklist in the kernel for the devices that are problematic (the ones that require open), but please don't prevent user space to have this blacklist and please do not make false assumptions in the kernel on the state of a switch. This is worse than it helps and in the end, user space won't be able to solve this if you change the default behavior at each release. Cheers, Benjamin > > Thanks and best regards > Lv > > > > > Link: https://bugzilla.gnome.org/show_bug.cgi?id=782380 > > Cc: stable@vger.kernel.org > > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> > > --- > > drivers/acpi/button.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c > > index 6d5a8c1..e19f530 100644 > > --- a/drivers/acpi/button.c > > +++ b/drivers/acpi/button.c > > @@ -113,7 +113,7 @@ struct acpi_button { > > > > static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier); > > static struct acpi_device *lid_device; > > -static u8 lid_init_state = ACPI_BUTTON_LID_INIT_OPEN; > > +static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD; > > > > static unsigned long lid_report_interval __read_mostly = 500; > > module_param(lid_report_interval, ulong, 0644); > > -- > > 2.9.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGksIA0KDQo+IEZyb206IEJlbmphbWluIFRpc3NvaXJlcyBbbWFpbHRvOmJlbmphbWluLnRpc3Nv aXJlc0ByZWRoYXQuY29tXQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIIDIvMl0gUmV2ZXJ0ICJBQ1BJ IC8gYnV0dG9uOiBDaGFuZ2UgZGVmYXVsdCBiZWhhdmlvciB0byBsaWRfaW5pdF9zdGF0ZT1vcGVu Ig0KPiANCj4gT24gTWF5IDExIDIwMTcgb3IgdGhlcmVhYm91dHMsIFpoZW5nLCBMdiB3cm90ZToN Cj4gPiBIaSwNCj4gPg0KPiA+ID4gRnJvbTogQmVuamFtaW4gVGlzc29pcmVzIFttYWlsdG86YmVu amFtaW4udGlzc29pcmVzQHJlZGhhdC5jb21dDQo+ID4gPiBTdWJqZWN0OiBbUEFUQ0ggMi8yXSBS ZXZlcnQgIkFDUEkgLyBidXR0b246IENoYW5nZSBkZWZhdWx0IGJlaGF2aW9yIHRvIGxpZF9pbml0 X3N0YXRlPW9wZW4iDQo+ID4gPg0KPiA+ID4gVGhpcyByZXZlcnRzIGNvbW1pdCA3N2U5YTRhYTlk ZTEwY2MxNDE4YmY5YTg5MjM2Njk4ODgwMmE4MDI1Lg0KPiA+ID4NCj4gPiA+IEV2ZW4gaWYgdGhl IG1ldGhvZCBpbXBsZW1lbnRhdGlvbiBjYW4gYmUgYnVnZ3kgb24gc29tZSBwbGF0Zm9ybSwNCj4g PiA+IHRoZSAib3BlbiIgY2hvaWNlIGlzIHdvcnNlLiBJdCBicmVha3MgZG9ja2luZyBzdGF0aW9u cyBiYXNpY2FsbHkNCj4gPiA+IGFuZCB0aGVyZSBpcyBubyB3YXkgdG8gaGF2ZSBhIHVzZXItc3Bh Y2UgaHdkYiB0byBmaXggdGhhdC4NCj4gPiA+DQo+ID4gPiBPbiB0aGUgY29udHJhcnksIGl0J3Mg cmF0aGVyIGVhc3kgaW4gdXNlci1zcGFjZSB0byBoYXZlIGEgaHdkYg0KPiA+ID4gd2l0aCB0aGUg cHJvYmxlbWF0aWMgcGxhdGZvcm1zLiBUaGVuLCBsaWJpbnB1dCAoMS43LjArKSBjYW4gZml4DQo+ ID4gPiB0aGUgc3RhdGUgb2YgdGhlIExJRCBzd2l0Y2ggZm9yIHVzOiB5b3UgbmVlZCB0byBzZXQg dGhlIHVkZXYNCj4gPiA+IHByb3BlcnR5IExJQklOUFVUX0FUVFJfTElEX1NXSVRDSF9SRUxJQUJJ TElUWSB0byAnd3JpdGVfb3BlbicuDQo+ID4gPg0KPiA+ID4gV2hlbiBsaWJpbnB1dCBkZXRlY3Rz IGludGVybmFsIGtleWJvYXJkIGV2ZW50cywgaXQgd2lsbA0KPiA+ID4gb3ZlcndyaXRlIHRoZSBz dGF0ZSBvZiB0aGUgc3dpdGNoIHRvIG9wZW4sIG1ha2luZyBpdCByZWxpYWJsZQ0KPiA+ID4gYWdh aW4uIEdpdmVuIHRoYXQgbG9naW5kIG9ubHkgY2hlY2tzIHRoZSBMSUQgc3dpdGNoIHZhbHVlIGFm dGVyDQo+ID4gPiBhIHRpbWVvdXQsIHdlIGNhbiBhc3N1bWUgdGhlIHVzZXIgd2lsbCB1c2UgdGhl IGludGVybmFsIGtleWJvYXJkDQo+ID4gPiBiZWZvcmUgdGhpcyB0aW1lb3V0IGV4cGlyZXMuDQo+ ID4gPg0KPiA+ID4gRm9yIGV4YW1wbGUsIHN1Y2ggYSBod2RiIGVudHJ5IGlzOg0KPiA+ID4NCj4g PiA+IGxpYmlucHV0Om5hbWU6KkxpZCBTd2l0Y2gqOmRtaToqc3ZuTWljcm9zb2Z0Q29ycG9yYXRp b246cG5TdXJmYWNlMzoqDQo+ID4gPiAgTElCSU5QVVRfQVRUUl9MSURfU1dJVENIX1JFTElBQklM SVRZPXdyaXRlX29wZW4NCj4gPg0KPiA+IEZvciB0aGUgcmVhc29uIG1lbnRpb25lZCBwcmV2aW91 c2x5IGFuZCBwcm9vZnMgaGVyZSAoc2VlIHBhdGNoIGRlc2NyaXB0aW9ucyk6DQo+ID4gaHR0cHM6 Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wYXRjaC85NzE3MTExLw0KPiANCj4gSSBhbSBub3Qgc3Vy ZSB5b3UgY2FuIGNhbGwgdGhpcyBwcm9vZnMuIFRoZSAiY2xvc2UiIHN0YXRlIGlzIElNTyB0aGUN Cj4gZXhhY3Qgc2FtZSBhcyB0aGUgIm1ldGhvZCIgb25lLCBpdCdzIGp1c3QgdGhhdCB0aGUgaW50 ZWwgZHJpdmVyDQo+IHRyaWdnZXJzIHRoZSBldmFsdWF0aW9uIG9mIHRoZSBfTElEIG1ldGhvZCwg bm90IGFjcGkvYnV0dG9uLmMuDQoNCkkgc2hvdWxkIGNvcnJlY3QgeW91IHRoYXQ6DQoxLiBpbnRl bF9sdmRzIGRyaXZlciBvbmx5IGV2YWx1YXRlcyBfTElEIG1ldGhvZCBmb3IgaXRzIG93biBwdXJw b3NlLA0KICAgU2VlIG15IHJlcGx5IHRvIFBBVENIIDQtNTsNCjIuIGFjcGkvYnV0dG9uLmMgaXMg c3RpbGwgcmVzcG9uc2libGUgZm9yIGdlbmVyYXRpbmcgdGhlIGxpZCBpbnB1dCBldmVudCAodG8g aW5wdXQgbGF5ZXIgYW5kIHRodXMgdGhlIHVzZXJzcGFjZSkNCiAgIEFuZCB0aGUgaW5wdXQgZXZl bnQgZ2VuZXJhdGVkIGJ5IGJ1dHRvbi5jIGRpZmZlcnMgZm9yIHRoZSAyIG1vZGVzLg0KICAgU2Vl IG15IGFub3RoZXIgcmVwbHkgdG8gUEFUQ0ggMDIuDQoNCj4gDQo+IEFuZCByZW1lbWJlciB0aGF0 IHRoaXMgbmV3IGRlZmF1bHQgcHJldmVudHMgdXNlcnNwYWNlIHRvIGZpeCBpdCBiZWNhdXNlDQo+ IGl0J3MgcmF0aGVyIGVhc3kgdG8gZGV0ZWN0IHRoYXQgdGhlIGRldmljZSBpcyBhY3R1YWxseSBv cGVuZWQgKGlucHV0DQo+IGV2ZW50cyBjb21pbmcgZnJvbSBpbnRlcmFubCBrZXlib2FyZCwgdG91 Y2hzY3JlZW4sIG9yIHRvdWNocGFkKSwgd2hpbGUNCj4gcmVwb3J0aW5nIHRoZSBsaWQgc3dpdGNo IGFzIG9wZW4gbWVhbnMgd2UgY2FuJ3Qga25vdyBpZiB0aGUgdXNlciBpcw0KPiBzaW1wbHkgbm90 IHVzaW5nIHRoZSBpbnRlcm5hbCBkZXZpY2VzLCBvciBpZiB3ZSBoYXZlIGp1c3QgYSB3cm9uZyBz dGF0ZS4NCg0KVGhhdCBkZXBlbmRzIG9uIHdoYXQgdGhlIG1lYW5pbmcgb2YgImZpeCIgaXMgSU1P Lg0KSSBzYXcgeW91IHdyb3RlIGEgbG90IGluIGFub3RoZXIgbWVzc2FnZSwgbGV0J3MgZGlzY3Vz cyB0aGlzIHRoZXJlLg0KDQo+IA0KPiBHaXZlbiB0aGF0IHRoaXMgcGF0Y2ggYnJlYWtzIGFsbCBM ZW5vdm9zIHdpdGggYSBkb2NrIChJIGNhbiBndWVzcyB0aGF0IDYNCj4gbGluZXMgdGhpcyB5ZWFy IGFyZSB1c2luZyBkb2NrcywgYW5kIHdpdGhpbiBlYWNoIGxpbmUgeW91IGhhdmUgMi01DQo+IHZh cmlhbnRzKSwgSSdkIHN1Z2dlc3Qgd2UgZG8gbm90IGJyZWFrIHRob3NlIGV4aXN0aW5nIGxhcHRv cHMgYW5kIGp1c3QNCj4gcmV2ZXJ0IHRoaXMgcGF0Y2guDQo+IA0KPiBJIHdvdWxkIHRoaW5rIG90 aGVyIE9FTXMgaGF2ZSBhIGRvY2tpbmcgc3RhdGlvbiB3aXRoIGFuIGFjdHVhbCBwb3dlcg0KPiBi dXR0b24gYnV0IEkgY2FuJ3QgYmUgc3VyZSBieSBsb29raW5nIGF0IHRoZSBwcm9kdWN0IHBhZ2Vz Lg0KDQpJJ20gbm90IHN1cmUgaWYgaXQgYnJlYWtzIHRoZSBleHRlcm5hbCBtb25pdG9yIHVzYWdl IG1vZGVsLg0KV2h5IGRvbid0IHRoZSB1c2Vyc3BhY2UganVzdA0KMS4gYWx3YXlzIGxpZ2h0IG9u IHRoZSBleHRlcm5hbCBkaXNwbGF5IGFuZCBrZWVwIHRoZSBpbnRlcm5hbCBkaXNwbGF5IG5vdCBs aXQgb24gYWZ0ZXIgYm9vdC9yZXN1bWUsIG9yDQoyLiBkb24ndCBkbyBhbnl0aGluZyBhbmQgbGV0 IHRoZSBCSU9TIHRvIGxpZ2h0IG9uIHRoZSByaWdodCBkaXNwbGF5LCBvcg0KMy4gZG9uJ3QgZG8g YW55dGhpbmcgYW5kIGxldCB0aGUgZ3JhcGhpY3MgZHJpdmVycyB0byBsaWdodCBvbiB0aGUgcmln aHQgZGlzcGxheSAodXNpbmcgc2F2ZWQgc3RhdGUgd2hlbiBzdXNwZW5kcyBhbmQgcmVzdW1lcyB0 byB0aGF0IHNhdmVkIHN0YXRlKS4NCg0KV2h5IHN1Y2ggZGVjaXNpb24gaGF2ZSB0byBiZSBtYWRl IGJhc2VkIG9uIEFDUEkgY29udHJvbCBtZXRob2QgbGlkIGRldmljZT8NCkkgY2Fubm90IHNlZSBh IHN0cm9uZyByZWFzb24gdGhhdCBBQ1BJIGNvbnRyb2wgbWV0aG9kIGxpZCBkZXZpY2UgbXVzdCBw YXJ0aWNpcGF0ZSBpbiB0aGlzIHVzYWdlIG1vZGVsLg0KDQpTZWUgZHJpdmVycy9ncHUvZHJtL25v dXZlYXUvbm91dmVhdV9jb25uZWN0b3IuYywNCnRoZSBpZ25vcmVsaWQgcGFyYW1ldGVyIHByb3Zl cyB0aGF0IHRoZSBncmFwaGljcyBkcml2ZXJzIGNhbiBkbyB0aGlzIG9uIHRoZWlyIG93biBhbmQg ZG8gdGhpcyBwZXJmZWN0bHkuDQogDQo+IA0KPiA+IFdlIHNob3VsZG4ndCBkbyB0aGlzLg0KPiAN Cj4gSSBzdHJvbmdseSBkaXNhZ3JlZS4NCj4gDQo+IEkgYW0gZmluZSBpZiB5b3UgZG9uJ3Qgd2Fu dCB0byBoYXZlIGEgYmxhY2tsaXN0IGluIHRoZSBrZXJuZWwgZm9yIHRoZQ0KPiBkZXZpY2VzIHRo YXQgYXJlIHByb2JsZW1hdGljICh0aGUgb25lcyB0aGF0IHJlcXVpcmUgb3BlbiksIGJ1dCBwbGVh c2UNCj4gZG9uJ3QgcHJldmVudCB1c2VyIHNwYWNlIHRvIGhhdmUgdGhpcyBibGFja2xpc3QgYW5k IHBsZWFzZSBkbyBub3QgbWFrZQ0KPiBmYWxzZSBhc3N1bXB0aW9ucyBpbiB0aGUga2VybmVsIG9u IHRoZSBzdGF0ZSBvZiBhIHN3aXRjaC4gVGhpcyBpcyB3b3JzZQ0KPiB0aGFuIGl0IGhlbHBzIGFu ZCBpbiB0aGUgZW5kLCB1c2VyIHNwYWNlIHdvbid0IGJlIGFibGUgdG8gc29sdmUgdGhpcyBpZg0K PiB5b3UgY2hhbmdlIHRoZSBkZWZhdWx0IGJlaGF2aW9yIGF0IGVhY2ggcmVsZWFzZS4NCg0KV2Ug YXJlIGFjdHVhbGx5IGFsc28gZmluZSB3aXRoIGFueSBkZWZhdWx0IHZhbHVlLg0KDQpCdXQgYmUg YXdhcmUgb2YgdGhhdCwgQUNQSSBzdWJzeXN0ZW0ganVzdCBwcm92aWRlcyBhIGJ1dHRvbiBkcml2 ZXI6DQoxLiBBbGxvd3MgdXNlcnMgdG8gc3VzcGVuZCB0aGUgc3lzdGVtIHVwb24gcmVjZWl2aW5n ICJjbG9zZSIgbGlkIGV2ZW50Ow0KMi4gU3RvcHMgdG8gc3VwcG9ydCBhbnkgb3RoZXIgdXNhZ2Ug bW9kZWxzIGJ1dCBpcyB3aWxsaW5nIHRvIHByb3ZpZGUgdHVuYWJsZSBiZWhhdmlvciBmb3IgdGhl IG90aGVyIHN5c3RlbSBwYXJ0aWNpcGFudHMgdG8gc3VwcG9ydCB0aGVpciBzcGVjaWFsIG5lZWRz Lg0KICAgU3VjaCBwYXJ0aWNpcGFudHMgaW5jbHVkZSBidXQgYXJlIG5vdCBsaW1pdGVkIHRvIHRo ZSB1c2VyIHNwYWNlIHRvb2xzIGFuZCB0aGUgb3RoZXIga2VybmVsIG1vZHVsZXMuDQogICBCdXQg dGhlIGRlZmF1bHQgYmVoYXZpb3IgYW5kIHRoZSB0aW1pbmcgb2YgdHVuaW5nIGJ1dHRvbiBkcml2 ZXIgYmVoYXZpb3JzIHNob3VsZCBiZSBkZXRlcm1pbmVkIGJ5IHRoZSBvdGhlciBzeXN0ZW0gcGFy dGljaXBhbnRzLg0KICAgQW5kIGFzIGEgY29uc2VxdWVuY2UsIHRoZSBvdGhlciBzeXN0ZW0gcGFy dGljaXBhbnRzIHdobyBjaGFuZ2UgdGhhdCBtdXN0IGJlIHJlc3BvbnNpYmxlIGZvciBmaXhpbmcg cmVncmVzc2lvbnMgcmVsYXRlZCB0byBjb25mbGljdHMgb2YgdGhlIG5lZWRzLg0KICAgQXMgc3Vj aCwgd2UgbmVlZCB0byBrbm93IHNvbWUgb2ZmaWNpYWwgYnVnIHJlcG9ydCB3aW5kb3cgdG8gZm9y d2FyZCBidWcgcmVwb3J0cyByZWxhdGVkIHRvIHRoYXQuDQogICBPdGhlcndpc2UsIEFDUEkgQnVn emlsbGEgY2FuIGJlIGZsb29kZWQgYnkgd3JvbmcgYnVncy4NCg0KQ2hlZXJzLA0KTHYNCg0KPiAN Cj4gQ2hlZXJzLA0KPiBCZW5qYW1pbg0KPiANCj4gPg0KPiA+IFRoYW5rcyBhbmQgYmVzdCByZWdh cmRzDQo+ID4gTHYNCj4gPg0KPiA+ID4NCj4gPiA+IExpbms6IGh0dHBzOi8vYnVnemlsbGEuZ25v bWUub3JnL3Nob3dfYnVnLmNnaT9pZD03ODIzODANCj4gPiA+IENjOiBzdGFibGVAdmdlci5rZXJu ZWwub3JnDQo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBCZW5qYW1pbiBUaXNzb2lyZXMgPGJlbmphbWlu LnRpc3NvaXJlc0ByZWRoYXQuY29tPg0KPiA+ID4gLS0tDQo+ID4gPiAgZHJpdmVycy9hY3BpL2J1 dHRvbi5jIHwgMiArLQ0KPiA+ID4gIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBk ZWxldGlvbigtKQ0KPiA+ID4NCj4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2FjcGkvYnV0dG9u LmMgYi9kcml2ZXJzL2FjcGkvYnV0dG9uLmMNCj4gPiA+IGluZGV4IDZkNWE4YzEuLmUxOWY1MzAg MTAwNjQ0DQo+ID4gPiAtLS0gYS9kcml2ZXJzL2FjcGkvYnV0dG9uLmMNCj4gPiA+ICsrKyBiL2Ry aXZlcnMvYWNwaS9idXR0b24uYw0KPiA+ID4gQEAgLTExMyw3ICsxMTMsNyBAQCBzdHJ1Y3QgYWNw aV9idXR0b24gew0KPiA+ID4NCj4gPiA+ICBzdGF0aWMgQkxPQ0tJTkdfTk9USUZJRVJfSEVBRChh Y3BpX2xpZF9ub3RpZmllcik7DQo+ID4gPiAgc3RhdGljIHN0cnVjdCBhY3BpX2RldmljZSAqbGlk X2RldmljZTsNCj4gPiA+IC1zdGF0aWMgdTggbGlkX2luaXRfc3RhdGUgPSBBQ1BJX0JVVFRPTl9M SURfSU5JVF9PUEVOOw0KPiA+ID4gK3N0YXRpYyB1OCBsaWRfaW5pdF9zdGF0ZSA9IEFDUElfQlVU VE9OX0xJRF9JTklUX01FVEhPRDsNCj4gPiA+DQo+ID4gPiAgc3RhdGljIHVuc2lnbmVkIGxvbmcg bGlkX3JlcG9ydF9pbnRlcnZhbCBfX3JlYWRfbW9zdGx5ID0gNTAwOw0KPiA+ID4gIG1vZHVsZV9w YXJhbShsaWRfcmVwb3J0X2ludGVydmFsLCB1bG9uZywgMDY0NCk7DQo+ID4gPiAtLQ0KPiA+ID4g Mi45LjMNCj4gPg0K -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > Hi, > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > > > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > > Hi, > > > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > > > > > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > > > > > > > > Even if the method implementation can be buggy on some platform, > > > > the "open" choice is worse. It breaks docking stations basically > > > > and there is no way to have a user-space hwdb to fix that. > > > > > > > > On the contrary, it's rather easy in user-space to have a hwdb > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix > > > > the state of the LID switch for us: you need to set the udev > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. > > > > > > > > When libinput detects internal keyboard events, it will > > > > overwrite the state of the switch to open, making it reliable > > > > again. Given that logind only checks the LID switch value after > > > > a timeout, we can assume the user will use the internal keyboard > > > > before this timeout expires. > > > > > > > > For example, such a hwdb entry is: > > > > > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > > > > > > For the reason mentioned previously and proofs here (see patch descriptions): > > > https://patchwork.kernel.org/patch/9717111/ > > > > I am not sure you can call this proofs. The "close" state is IMO the > > exact same as the "method" one, it's just that the intel driver > > triggers the evaluation of the _LID method, not acpi/button.c. > > I should correct you that: > 1. intel_lvds driver only evaluates _LID method for its own purpose, > See my reply to PATCH 4-5; > 2. acpi/button.c is still responsible for generating the lid input event (to input layer and thus the userspace) > And the input event generated by button.c differs for the 2 modes. > See my another reply to PATCH 02. > > > > > And remember that this new default prevents userspace to fix it because > > it's rather easy to detect that the device is actually opened (input > > events coming from interanl keyboard, touchscreen, or touchpad), while > > reporting the lid switch as open means we can't know if the user is > > simply not using the internal devices, or if we have just a wrong state. > > That depends on what the meaning of "fix" is IMO. > I saw you wrote a lot in another message, let's discuss this there. > > > > > Given that this patch breaks all Lenovos with a dock (I can guess that 6 > > lines this year are using docks, and within each line you have 2-5 > > variants), I'd suggest we do not break those existing laptops and just > > revert this patch. > > > > I would think other OEMs have a docking station with an actual power > > button but I can't be sure by looking at the product pages. > > I'm not sure if it breaks the external monitor usage model. Well, if it worked in a specific way that users depended on before the commit in question and now it works differently, then it does break things. Benjamin, my understanding is that this is the case, is it correct? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > > Hi, > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > > > > > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > > > Hi, > > > > > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > > > > > > > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > > > > > > > > > > Even if the method implementation can be buggy on some platform, > > > > > the "open" choice is worse. It breaks docking stations basically > > > > > and there is no way to have a user-space hwdb to fix that. > > > > > > > > > > On the contrary, it's rather easy in user-space to have a hwdb > > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix > > > > > the state of the LID switch for us: you need to set the udev > > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. > > > > > > > > > > When libinput detects internal keyboard events, it will > > > > > overwrite the state of the switch to open, making it reliable > > > > > again. Given that logind only checks the LID switch value after > > > > > a timeout, we can assume the user will use the internal keyboard > > > > > before this timeout expires. > > > > > > > > > > For example, such a hwdb entry is: > > > > > > > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > > > > [...] > > Well, if it worked in a specific way that users depended on before the commit in > question and now it works differently, then it does break things. > > Benjamin, my understanding is that this is the case, is it correct? That is correct. This patch I reverted introduces regression for professional laptops that expect the LID switch to be reported accurately. Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote: > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: >> > Hi, >> > >> > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" >> > > >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote: >> > > > Hi, >> > > > >> > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" >> > > > > >> > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. >> > > > > >> > > > > Even if the method implementation can be buggy on some platform, >> > > > > the "open" choice is worse. It breaks docking stations basically >> > > > > and there is no way to have a user-space hwdb to fix that. >> > > > > >> > > > > On the contrary, it's rather easy in user-space to have a hwdb >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix >> > > > > the state of the LID switch for us: you need to set the udev >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. >> > > > > >> > > > > When libinput detects internal keyboard events, it will >> > > > > overwrite the state of the switch to open, making it reliable >> > > > > again. Given that logind only checks the LID switch value after >> > > > > a timeout, we can assume the user will use the internal keyboard >> > > > > before this timeout expires. >> > > > > >> > > > > For example, such a hwdb entry is: >> > > > > >> > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open >> > > > > > [...] > >> >> Well, if it worked in a specific way that users depended on before the commit in >> question and now it works differently, then it does break things. >> >> Benjamin, my understanding is that this is the case, is it correct? > > That is correct. This patch I reverted introduces regression for professional > laptops that expect the LID switch to be reported accurately. And from a user's perspective, what does not work any more? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires > <benjamin.tissoires@redhat.com> wrote: > > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > >> > Hi, > >> > > >> > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > >> > > > >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > >> > > > Hi, > >> > > > > >> > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > >> > > > > > >> > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > >> > > > > > >> > > > > Even if the method implementation can be buggy on some platform, > >> > > > > the "open" choice is worse. It breaks docking stations basically > >> > > > > and there is no way to have a user-space hwdb to fix that. > >> > > > > > >> > > > > On the contrary, it's rather easy in user-space to have a hwdb > >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix > >> > > > > the state of the LID switch for us: you need to set the udev > >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. > >> > > > > > >> > > > > When libinput detects internal keyboard events, it will > >> > > > > overwrite the state of the switch to open, making it reliable > >> > > > > again. Given that logind only checks the LID switch value after > >> > > > > a timeout, we can assume the user will use the internal keyboard > >> > > > > before this timeout expires. > >> > > > > > >> > > > > For example, such a hwdb entry is: > >> > > > > > >> > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > >> > > > > > > > [...] > > > >> > >> Well, if it worked in a specific way that users depended on before the commit in > >> question and now it works differently, then it does break things. > >> > >> Benjamin, my understanding is that this is the case, is it correct? > > > > That is correct. This patch I reverted introduces regression for professional > > laptops that expect the LID switch to be reported accurately. > > And from a user's perspective, what does not work any more? If you boot or resume your laptop with the lid closed on a docking station while using an external monitor connected to it, both internal and external displays will light on, while only the external should. There is a design choice in gdm to only provide the greater on the internal display when lit on, so users only see a gray area on the external monitor. Also, the cursor will not show up as it's by default on the internal display too. To "fix" that, users have to open the laptop once and close it once again to sync the state of the switch with the hardware state. Cheers, Benjamin > > Thanks, > Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote: > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires >> <benjamin.tissoires@redhat.com> wrote: >> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: >> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: >> >> > Hi, >> >> > >> >> > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] >> >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" >> >> > > >> >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote: >> >> > > > Hi, >> >> > > > >> >> > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] >> >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" >> >> > > > > >> >> > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. >> >> > > > > >> >> > > > > Even if the method implementation can be buggy on some platform, >> >> > > > > the "open" choice is worse. It breaks docking stations basically >> >> > > > > and there is no way to have a user-space hwdb to fix that. >> >> > > > > >> >> > > > > On the contrary, it's rather easy in user-space to have a hwdb >> >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix >> >> > > > > the state of the LID switch for us: you need to set the udev >> >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. >> >> > > > > >> >> > > > > When libinput detects internal keyboard events, it will >> >> > > > > overwrite the state of the switch to open, making it reliable >> >> > > > > again. Given that logind only checks the LID switch value after >> >> > > > > a timeout, we can assume the user will use the internal keyboard >> >> > > > > before this timeout expires. >> >> > > > > >> >> > > > > For example, such a hwdb entry is: >> >> > > > > >> >> > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* >> >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open >> >> > > > >> > >> > [...] >> > >> >> >> >> Well, if it worked in a specific way that users depended on before the commit in >> >> question and now it works differently, then it does break things. >> >> >> >> Benjamin, my understanding is that this is the case, is it correct? >> > >> > That is correct. This patch I reverted introduces regression for professional >> > laptops that expect the LID switch to be reported accurately. >> >> And from a user's perspective, what does not work any more? > > If you boot or resume your laptop with the lid closed on a docking > station while using an external monitor connected to it, both internal > and external displays will light on, while only the external should. > > There is a design choice in gdm to only provide the greater on the > internal display when lit on, so users only see a gray area on the > external monitor. Also, the cursor will not show up as it's by default > on the internal display too. > > To "fix" that, users have to open the laptop once and close it once > again to sync the state of the switch with the hardware state. OK Yeah, that sucks. So without the Lv's patch the behavior (on the systems in question) is as expected, right? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires > <benjamin.tissoires@redhat.com> wrote: > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires > >> <benjamin.tissoires@redhat.com> wrote: > >> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > >> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > >> >> > Hi, > >> >> > > >> >> > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > >> >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > >> >> > > > >> >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > >> >> > > > Hi, > >> >> > > > > >> >> > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > >> >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > >> >> > > > > > >> >> > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > >> >> > > > > > >> >> > > > > Even if the method implementation can be buggy on some platform, > >> >> > > > > the "open" choice is worse. It breaks docking stations basically > >> >> > > > > and there is no way to have a user-space hwdb to fix that. > >> >> > > > > > >> >> > > > > On the contrary, it's rather easy in user-space to have a hwdb > >> >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix > >> >> > > > > the state of the LID switch for us: you need to set the udev > >> >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. > >> >> > > > > > >> >> > > > > When libinput detects internal keyboard events, it will > >> >> > > > > overwrite the state of the switch to open, making it reliable > >> >> > > > > again. Given that logind only checks the LID switch value after > >> >> > > > > a timeout, we can assume the user will use the internal keyboard > >> >> > > > > before this timeout expires. > >> >> > > > > > >> >> > > > > For example, such a hwdb entry is: > >> >> > > > > > >> >> > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > >> >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > >> >> > > > > >> > > >> > [...] > >> > > >> >> > >> >> Well, if it worked in a specific way that users depended on before the commit in > >> >> question and now it works differently, then it does break things. > >> >> > >> >> Benjamin, my understanding is that this is the case, is it correct? > >> > > >> > That is correct. This patch I reverted introduces regression for professional > >> > laptops that expect the LID switch to be reported accurately. > >> > >> And from a user's perspective, what does not work any more? > > > > If you boot or resume your laptop with the lid closed on a docking > > station while using an external monitor connected to it, both internal > > and external displays will light on, while only the external should. > > > > There is a design choice in gdm to only provide the greater on the > > internal display when lit on, so users only see a gray area on the > > external monitor. Also, the cursor will not show up as it's by default > > on the internal display too. > > > > To "fix" that, users have to open the laptop once and close it once > > again to sync the state of the switch with the hardware state. > > OK > > Yeah, that sucks. > > So without the Lv's patch the behavior (on the systems in question) is > as expected, right? > Yes, reverting these 2 patches restores the pre v4.11 kernel behavior. Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGksIEd1eXMNCg0KPiBGcm9tOiBCZW5qYW1pbiBUaXNzb2lyZXMgW21haWx0bzpiZW5qYW1pbi50 aXNzb2lyZXNAcmVkaGF0LmNvbV0NCj4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzJdIFJldmVydCAi QUNQSSAvIGJ1dHRvbjogQ2hhbmdlIGRlZmF1bHQgYmVoYXZpb3IgdG8gbGlkX2luaXRfc3RhdGU9 b3BlbiINCj4gDQo+IE9uIE1heSAxNSAyMDE3IG9yIHRoZXJlYWJvdXRzLCBSYWZhZWwgSi4gV3lz b2NraSB3cm90ZToNCj4gPiBPbiBNb24sIE1heSAxNSwgMjAxNyBhdCAxMTozNyBBTSwgQmVuamFt aW4gVGlzc29pcmVzDQo+ID4gPGJlbmphbWluLnRpc3NvaXJlc0ByZWRoYXQuY29tPiB3cm90ZToN Cj4gPiA+IE9uIE1heSAxNSAyMDE3IG9yIHRoZXJlYWJvdXRzLCBSYWZhZWwgSi4gV3lzb2NraSB3 cm90ZToNCj4gPiA+PiBPbiBNb24sIE1heSAxNSwgMjAxNyBhdCA5OjQ1IEFNLCBCZW5qYW1pbiBU aXNzb2lyZXMNCj4gPiA+PiA8YmVuamFtaW4udGlzc29pcmVzQHJlZGhhdC5jb20+IHdyb3RlOg0K PiA+ID4+ID4gT24gTWF5IDEyIDIwMTcgb3IgdGhlcmVhYm91dHMsIFJhZmFlbCBKLiBXeXNvY2tp IHdyb3RlOg0KPiA+ID4+ID4+IE9uIEZyaWRheSwgTWF5IDEyLCAyMDE3IDAyOjM2OjIwIEFNIFpo ZW5nLCBMdiB3cm90ZToNCj4gPiA+PiA+PiA+IEhpLA0KPiA+ID4+ID4+ID4NCj4gPiA+PiA+PiA+ ID4gRnJvbTogQmVuamFtaW4gVGlzc29pcmVzIFttYWlsdG86YmVuamFtaW4udGlzc29pcmVzQHJl ZGhhdC5jb21dDQo+ID4gPj4gPj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8yXSBSZXZlcnQg IkFDUEkgLyBidXR0b246IENoYW5nZSBkZWZhdWx0IGJlaGF2aW9yIHRvDQo+IGxpZF9pbml0X3N0 YXRlPW9wZW4iDQo+ID4gPj4gPj4gPiA+DQo+ID4gPj4gPj4gPiA+IE9uIE1heSAxMSAyMDE3IG9y IHRoZXJlYWJvdXRzLCBaaGVuZywgTHYgd3JvdGU6DQo+ID4gPj4gPj4gPiA+ID4gSGksDQo+ID4g Pj4gPj4gPiA+ID4NCj4gPiA+PiA+PiA+ID4gPiA+IEZyb206IEJlbmphbWluIFRpc3NvaXJlcyBb bWFpbHRvOmJlbmphbWluLnRpc3NvaXJlc0ByZWRoYXQuY29tXQ0KPiA+ID4+ID4+ID4gPiA+ID4g U3ViamVjdDogW1BBVENIIDIvMl0gUmV2ZXJ0ICJBQ1BJIC8gYnV0dG9uOiBDaGFuZ2UgZGVmYXVs dCBiZWhhdmlvciB0bw0KPiBsaWRfaW5pdF9zdGF0ZT1vcGVuIg0KPiA+ID4+ID4+ID4gPiA+ID4N Cj4gPiA+PiA+PiA+ID4gPiA+IFRoaXMgcmV2ZXJ0cyBjb21taXQgNzdlOWE0YWE5ZGUxMGNjMTQx OGJmOWE4OTIzNjY5ODg4MDJhODAyNS4NCj4gPiA+PiA+PiA+ID4gPiA+DQo+ID4gPj4gPj4gPiA+ ID4gPiBFdmVuIGlmIHRoZSBtZXRob2QgaW1wbGVtZW50YXRpb24gY2FuIGJlIGJ1Z2d5IG9uIHNv bWUgcGxhdGZvcm0sDQo+ID4gPj4gPj4gPiA+ID4gPiB0aGUgIm9wZW4iIGNob2ljZSBpcyB3b3Jz ZS4gSXQgYnJlYWtzIGRvY2tpbmcgc3RhdGlvbnMgYmFzaWNhbGx5DQo+ID4gPj4gPj4gPiA+ID4g PiBhbmQgdGhlcmUgaXMgbm8gd2F5IHRvIGhhdmUgYSB1c2VyLXNwYWNlIGh3ZGIgdG8gZml4IHRo YXQuDQo+ID4gPj4gPj4gPiA+ID4gPg0KPiA+ID4+ID4+ID4gPiA+ID4gT24gdGhlIGNvbnRyYXJ5 LCBpdCdzIHJhdGhlciBlYXN5IGluIHVzZXItc3BhY2UgdG8gaGF2ZSBhIGh3ZGINCj4gPiA+PiA+ PiA+ID4gPiA+IHdpdGggdGhlIHByb2JsZW1hdGljIHBsYXRmb3Jtcy4gVGhlbiwgbGliaW5wdXQg KDEuNy4wKykgY2FuIGZpeA0KPiA+ID4+ID4+ID4gPiA+ID4gdGhlIHN0YXRlIG9mIHRoZSBMSUQg c3dpdGNoIGZvciB1czogeW91IG5lZWQgdG8gc2V0IHRoZSB1ZGV2DQo+ID4gPj4gPj4gPiA+ID4g PiBwcm9wZXJ0eSBMSUJJTlBVVF9BVFRSX0xJRF9TV0lUQ0hfUkVMSUFCSUxJVFkgdG8gJ3dyaXRl X29wZW4nLg0KPiA+ID4+ID4+ID4gPiA+ID4NCj4gPiA+PiA+PiA+ID4gPiA+IFdoZW4gbGliaW5w dXQgZGV0ZWN0cyBpbnRlcm5hbCBrZXlib2FyZCBldmVudHMsIGl0IHdpbGwNCj4gPiA+PiA+PiA+ ID4gPiA+IG92ZXJ3cml0ZSB0aGUgc3RhdGUgb2YgdGhlIHN3aXRjaCB0byBvcGVuLCBtYWtpbmcg aXQgcmVsaWFibGUNCj4gPiA+PiA+PiA+ID4gPiA+IGFnYWluLiBHaXZlbiB0aGF0IGxvZ2luZCBv bmx5IGNoZWNrcyB0aGUgTElEIHN3aXRjaCB2YWx1ZSBhZnRlcg0KPiA+ID4+ID4+ID4gPiA+ID4g YSB0aW1lb3V0LCB3ZSBjYW4gYXNzdW1lIHRoZSB1c2VyIHdpbGwgdXNlIHRoZSBpbnRlcm5hbCBr ZXlib2FyZA0KPiA+ID4+ID4+ID4gPiA+ID4gYmVmb3JlIHRoaXMgdGltZW91dCBleHBpcmVzLg0K PiA+ID4+ID4+ID4gPiA+ID4NCj4gPiA+PiA+PiA+ID4gPiA+IEZvciBleGFtcGxlLCBzdWNoIGEg aHdkYiBlbnRyeSBpczoNCj4gPiA+PiA+PiA+ID4gPiA+DQo+ID4gPj4gPj4gPiA+ID4gPiBsaWJp bnB1dDpuYW1lOipMaWQgU3dpdGNoKjpkbWk6KnN2bk1pY3Jvc29mdENvcnBvcmF0aW9uOnBuU3Vy ZmFjZTM6Kg0KPiA+ID4+ID4+ID4gPiA+ID4gIExJQklOUFVUX0FUVFJfTElEX1NXSVRDSF9SRUxJ QUJJTElUWT13cml0ZV9vcGVuDQo+ID4gPj4gPj4gPiA+ID4NCj4gPiA+PiA+DQo+ID4gPj4gPiBb Li4uXQ0KPiA+ID4+ID4NCj4gPiA+PiA+Pg0KPiA+ID4+ID4+IFdlbGwsIGlmIGl0IHdvcmtlZCBp biBhIHNwZWNpZmljIHdheSB0aGF0IHVzZXJzIGRlcGVuZGVkIG9uIGJlZm9yZSB0aGUgY29tbWl0 IGluDQo+ID4gPj4gPj4gcXVlc3Rpb24gYW5kIG5vdyBpdCB3b3JrcyBkaWZmZXJlbnRseSwgdGhl biBpdCBkb2VzIGJyZWFrIHRoaW5ncy4NCj4gPiA+PiA+Pg0KPiA+ID4+ID4+IEJlbmphbWluLCBt eSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBpcyB0aGUgY2FzZSwgaXMgaXQgY29ycmVjdD8N Cj4gPiA+PiA+DQo+ID4gPj4gPiBUaGF0IGlzIGNvcnJlY3QuIFRoaXMgcGF0Y2ggSSByZXZlcnRl ZCBpbnRyb2R1Y2VzIHJlZ3Jlc3Npb24gZm9yIHByb2Zlc3Npb25hbA0KPiA+ID4+ID4gbGFwdG9w cyB0aGF0IGV4cGVjdCB0aGUgTElEIHN3aXRjaCB0byBiZSByZXBvcnRlZCBhY2N1cmF0ZWx5Lg0K PiA+ID4+DQo+ID4gPj4gQW5kIGZyb20gYSB1c2VyJ3MgcGVyc3BlY3RpdmUsIHdoYXQgZG9lcyBu b3Qgd29yayBhbnkgbW9yZT8NCj4gPiA+DQo+ID4gPiBJZiB5b3UgYm9vdCBvciByZXN1bWUgeW91 ciBsYXB0b3Agd2l0aCB0aGUgbGlkIGNsb3NlZCBvbiBhIGRvY2tpbmcNCj4gPiA+IHN0YXRpb24g d2hpbGUgdXNpbmcgYW4gZXh0ZXJuYWwgbW9uaXRvciBjb25uZWN0ZWQgdG8gaXQsIGJvdGggaW50 ZXJuYWwNCj4gPiA+IGFuZCBleHRlcm5hbCBkaXNwbGF5cyB3aWxsIGxpZ2h0IG9uLCB3aGlsZSBv bmx5IHRoZSBleHRlcm5hbCBzaG91bGQuDQo+ID4gPg0KPiA+ID4gVGhlcmUgaXMgYSBkZXNpZ24g Y2hvaWNlIGluIGdkbSB0byBvbmx5IHByb3ZpZGUgdGhlIGdyZWF0ZXIgb24gdGhlDQo+ID4gPiBp bnRlcm5hbCBkaXNwbGF5IHdoZW4gbGl0IG9uLCBzbyB1c2VycyBvbmx5IHNlZSBhIGdyYXkgYXJl YSBvbiB0aGUNCj4gPiA+IGV4dGVybmFsIG1vbml0b3IuIEFsc28sIHRoZSBjdXJzb3Igd2lsbCBu b3Qgc2hvdyB1cCBhcyBpdCdzIGJ5IGRlZmF1bHQNCj4gPiA+IG9uIHRoZSBpbnRlcm5hbCBkaXNw bGF5IHRvby4NCj4gPiA+DQo+ID4gPiBUbyAiZml4IiB0aGF0LCB1c2VycyBoYXZlIHRvIG9wZW4g dGhlIGxhcHRvcCBvbmNlIGFuZCBjbG9zZSBpdCBvbmNlDQo+ID4gPiBhZ2FpbiB0byBzeW5jIHRo ZSBzdGF0ZSBvZiB0aGUgc3dpdGNoIHdpdGggdGhlIGhhcmR3YXJlIHN0YXRlLg0KPiA+DQo+ID4g T0sNCj4gPg0KPiA+IFllYWgsIHRoYXQgc3Vja3MuDQo+ID4NCj4gPiBTbyB3aXRob3V0IHRoZSBM didzIHBhdGNoIHRoZSBiZWhhdmlvciAob24gdGhlIHN5c3RlbXMgaW4gcXVlc3Rpb24pIGlzDQo+ ID4gYXMgZXhwZWN0ZWQsIHJpZ2h0Pw0KPiA+DQo+IA0KPiBZZXMsIHJldmVydGluZyB0aGVzZSAy IHBhdGNoZXMgcmVzdG9yZXMgdGhlIHByZSB2NC4xMSBrZXJuZWwgYmVoYXZpb3IuDQoNCkkgd291 bGQgbWFrZSBhbiBhcmd1bWVudCB0aGF0Og0KQS4gSXMgdGhpcyBuZWNlc3NhcmlseSBhIGJ1dHRv biBkcml2ZXIgcmVncmVzc2lvbj8NCjEuIFVzZXJzIGFscmVhZHkgY29uZmlndXJlZCB0byBub3Qg dXNpbmcgaW50ZXJuYWwgZGlzcGxheSwgd2h5IGdkbSBuZWVkIHRvIGRldGVybWluZSBpdCBhZ2Fp biBpbnN0ZWFkIG9mIHVzZXJzIGNob2ljZT8NCjIuIENhbiBnZG0vZ3JhcGhpY3MgZHJpdmVyIHNh dmVzIHN0YXRlIGJlZm9yZSBzdXNwZW5kLCBhbmQgcmVzdG9yZXMgc2F2ZWQgc3RhdGUgYWZ0ZXIg cmVzdW1lPw0KICAgSWYgdXNlcnMgZGlkbid0IGNoYW5nZSBzdGF0ZSBkdXJpbmcgc3VzcGVuZCwg dGhlbiBldmVyeXRoaW5nIHNob3VsZCBiZSBjb3JyZWN0Lg0KICAgSWYgdXNlcnMgY2hhbmdlZCBz dGF0ZSBkdXJpbmcgc3VzcGVuZCwgaXQgc2hvdWxkIGJlIGFjY2VwdGFibGUgZm9yIHVzZXJzIHRv IGNoYW5nZSBpdCBhZ2FpbiB0byBtYWtlIHRoZSBzdGF0ZSBjb3JyZWN0Lg0KU2VlLCB0aGlzIGlz IG9idmlvdXNseSBhIGNhc2UgdGhhdCBpcyBub3Qgc28gc3RyaWN0bHkgcmVsYXRlZCB0byBBQ1BJ IGJ1dHRvbiBkcml2ZXIuDQpXaHkgZG8gd2UgbmVlZCB0byBmb3JjZSBidXR0b24gZHJpdmVyIHRv IG1hcnJ5IGV4dGVybmFsIG1vbml0b3JzLg0KQi4gQnVnIHJlcG9ydGVycyBhcmUgYWxsIG9rIHdp dGggdXNpbmcgcXVpcmsgbW9kZXMgYXMgYm9vdCBwYXJhbWV0ZXJzIHRvIHdvcmsgdGhpcyBhcm91 bmQuDQpXaHkgc2hvdWxkIHdlIGNoYW5nZSBvdXIgZGVmYXVsdCBiZWhhdmlvciBhaW1sZXNzbHk/ DQoNClRoYW5rcyBhbmQgYmVzdCByZWdhcmRzDQpMdg0K -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGksDQoNCj4gRnJvbTogbGludXgtYWNwaS1vd25lckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzps aW51eC1hY3BpLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24gQmVoYWxmIE9mIFpoZW5nLA0KPiBM dg0KPiBTdWJqZWN0OiBSRTogW1BBVENIIDIvMl0gUmV2ZXJ0ICJBQ1BJIC8gYnV0dG9uOiBDaGFu Z2UgZGVmYXVsdCBiZWhhdmlvciB0byBsaWRfaW5pdF9zdGF0ZT1vcGVuIg0KPiANCj4gSGksIEd1 eXMNCj4gDQo+ID4gRnJvbTogQmVuamFtaW4gVGlzc29pcmVzIFttYWlsdG86YmVuamFtaW4udGlz c29pcmVzQHJlZGhhdC5jb21dDQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzJdIFJldmVydCAi QUNQSSAvIGJ1dHRvbjogQ2hhbmdlIGRlZmF1bHQgYmVoYXZpb3IgdG8gbGlkX2luaXRfc3RhdGU9 b3BlbiINCj4gPg0KPiA+IE9uIE1heSAxNSAyMDE3IG9yIHRoZXJlYWJvdXRzLCBSYWZhZWwgSi4g V3lzb2NraSB3cm90ZToNCj4gPiA+IE9uIE1vbiwgTWF5IDE1LCAyMDE3IGF0IDExOjM3IEFNLCBC ZW5qYW1pbiBUaXNzb2lyZXMNCj4gPiA+IDxiZW5qYW1pbi50aXNzb2lyZXNAcmVkaGF0LmNvbT4g d3JvdGU6DQo+ID4gPiA+IE9uIE1heSAxNSAyMDE3IG9yIHRoZXJlYWJvdXRzLCBSYWZhZWwgSi4g V3lzb2NraSB3cm90ZToNCj4gPiA+ID4+IE9uIE1vbiwgTWF5IDE1LCAyMDE3IGF0IDk6NDUgQU0s IEJlbmphbWluIFRpc3NvaXJlcw0KPiA+ID4gPj4gPGJlbmphbWluLnRpc3NvaXJlc0ByZWRoYXQu Y29tPiB3cm90ZToNCj4gPiA+ID4+ID4gT24gTWF5IDEyIDIwMTcgb3IgdGhlcmVhYm91dHMsIFJh ZmFlbCBKLiBXeXNvY2tpIHdyb3RlOg0KPiA+ID4gPj4gPj4gT24gRnJpZGF5LCBNYXkgMTIsIDIw MTcgMDI6MzY6MjAgQU0gWmhlbmcsIEx2IHdyb3RlOg0KPiA+ID4gPj4gPj4gPiBIaSwNCj4gPiA+ ID4+ID4+ID4NCj4gPiA+ID4+ID4+ID4gPiBGcm9tOiBCZW5qYW1pbiBUaXNzb2lyZXMgW21haWx0 bzpiZW5qYW1pbi50aXNzb2lyZXNAcmVkaGF0LmNvbV0NCj4gPiA+ID4+ID4+ID4gPiBTdWJqZWN0 OiBSZTogW1BBVENIIDIvMl0gUmV2ZXJ0ICJBQ1BJIC8gYnV0dG9uOiBDaGFuZ2UgZGVmYXVsdCBi ZWhhdmlvciB0bw0KPiA+IGxpZF9pbml0X3N0YXRlPW9wZW4iDQo+ID4gPiA+PiA+PiA+ID4NCj4g PiA+ID4+ID4+ID4gPiBPbiBNYXkgMTEgMjAxNyBvciB0aGVyZWFib3V0cywgWmhlbmcsIEx2IHdy b3RlOg0KPiA+ID4gPj4gPj4gPiA+ID4gSGksDQo+ID4gPiA+PiA+PiA+ID4gPg0KPiA+ID4gPj4g Pj4gPiA+ID4gPiBGcm9tOiBCZW5qYW1pbiBUaXNzb2lyZXMgW21haWx0bzpiZW5qYW1pbi50aXNz b2lyZXNAcmVkaGF0LmNvbV0NCj4gPiA+ID4+ID4+ID4gPiA+ID4gU3ViamVjdDogW1BBVENIIDIv Ml0gUmV2ZXJ0ICJBQ1BJIC8gYnV0dG9uOiBDaGFuZ2UgZGVmYXVsdCBiZWhhdmlvciB0bw0KPiA+ IGxpZF9pbml0X3N0YXRlPW9wZW4iDQo+ID4gPiA+PiA+PiA+ID4gPiA+DQo+ID4gPiA+PiA+PiA+ ID4gPiA+IFRoaXMgcmV2ZXJ0cyBjb21taXQgNzdlOWE0YWE5ZGUxMGNjMTQxOGJmOWE4OTIzNjY5 ODg4MDJhODAyNS4NCj4gPiA+ID4+ID4+ID4gPiA+ID4NCj4gPiA+ID4+ID4+ID4gPiA+ID4gRXZl biBpZiB0aGUgbWV0aG9kIGltcGxlbWVudGF0aW9uIGNhbiBiZSBidWdneSBvbiBzb21lIHBsYXRm b3JtLA0KPiA+ID4gPj4gPj4gPiA+ID4gPiB0aGUgIm9wZW4iIGNob2ljZSBpcyB3b3JzZS4gSXQg YnJlYWtzIGRvY2tpbmcgc3RhdGlvbnMgYmFzaWNhbGx5DQo+ID4gPiA+PiA+PiA+ID4gPiA+IGFu ZCB0aGVyZSBpcyBubyB3YXkgdG8gaGF2ZSBhIHVzZXItc3BhY2UgaHdkYiB0byBmaXggdGhhdC4N Cj4gPiA+ID4+ID4+ID4gPiA+ID4NCj4gPiA+ID4+ID4+ID4gPiA+ID4gT24gdGhlIGNvbnRyYXJ5 LCBpdCdzIHJhdGhlciBlYXN5IGluIHVzZXItc3BhY2UgdG8gaGF2ZSBhIGh3ZGINCj4gPiA+ID4+ ID4+ID4gPiA+ID4gd2l0aCB0aGUgcHJvYmxlbWF0aWMgcGxhdGZvcm1zLiBUaGVuLCBsaWJpbnB1 dCAoMS43LjArKSBjYW4gZml4DQo+ID4gPiA+PiA+PiA+ID4gPiA+IHRoZSBzdGF0ZSBvZiB0aGUg TElEIHN3aXRjaCBmb3IgdXM6IHlvdSBuZWVkIHRvIHNldCB0aGUgdWRldg0KPiA+ID4gPj4gPj4g PiA+ID4gPiBwcm9wZXJ0eSBMSUJJTlBVVF9BVFRSX0xJRF9TV0lUQ0hfUkVMSUFCSUxJVFkgdG8g J3dyaXRlX29wZW4nLg0KPiA+ID4gPj4gPj4gPiA+ID4gPg0KPiA+ID4gPj4gPj4gPiA+ID4gPiBX aGVuIGxpYmlucHV0IGRldGVjdHMgaW50ZXJuYWwga2V5Ym9hcmQgZXZlbnRzLCBpdCB3aWxsDQo+ ID4gPiA+PiA+PiA+ID4gPiA+IG92ZXJ3cml0ZSB0aGUgc3RhdGUgb2YgdGhlIHN3aXRjaCB0byBv cGVuLCBtYWtpbmcgaXQgcmVsaWFibGUNCj4gPiA+ID4+ID4+ID4gPiA+ID4gYWdhaW4uIEdpdmVu IHRoYXQgbG9naW5kIG9ubHkgY2hlY2tzIHRoZSBMSUQgc3dpdGNoIHZhbHVlIGFmdGVyDQo+ID4g PiA+PiA+PiA+ID4gPiA+IGEgdGltZW91dCwgd2UgY2FuIGFzc3VtZSB0aGUgdXNlciB3aWxsIHVz ZSB0aGUgaW50ZXJuYWwga2V5Ym9hcmQNCj4gPiA+ID4+ID4+ID4gPiA+ID4gYmVmb3JlIHRoaXMg dGltZW91dCBleHBpcmVzLg0KPiA+ID4gPj4gPj4gPiA+ID4gPg0KPiA+ID4gPj4gPj4gPiA+ID4g PiBGb3IgZXhhbXBsZSwgc3VjaCBhIGh3ZGIgZW50cnkgaXM6DQo+ID4gPiA+PiA+PiA+ID4gPiA+ DQo+ID4gPiA+PiA+PiA+ID4gPiA+IGxpYmlucHV0Om5hbWU6KkxpZCBTd2l0Y2gqOmRtaToqc3Zu TWljcm9zb2Z0Q29ycG9yYXRpb246cG5TdXJmYWNlMzoqDQo+ID4gPiA+PiA+PiA+ID4gPiA+ICBM SUJJTlBVVF9BVFRSX0xJRF9TV0lUQ0hfUkVMSUFCSUxJVFk9d3JpdGVfb3Blbg0KPiA+ID4gPj4g Pj4gPiA+ID4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gWy4uLl0NCj4gPiA+ID4+ID4NCj4gPiA+ ID4+ID4+DQo+ID4gPiA+PiA+PiBXZWxsLCBpZiBpdCB3b3JrZWQgaW4gYSBzcGVjaWZpYyB3YXkg dGhhdCB1c2VycyBkZXBlbmRlZCBvbiBiZWZvcmUgdGhlIGNvbW1pdCBpbg0KPiA+ID4gPj4gPj4g cXVlc3Rpb24gYW5kIG5vdyBpdCB3b3JrcyBkaWZmZXJlbnRseSwgdGhlbiBpdCBkb2VzIGJyZWFr IHRoaW5ncy4NCj4gPiA+ID4+ID4+DQo+ID4gPiA+PiA+PiBCZW5qYW1pbiwgbXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IHRoaXMgaXMgdGhlIGNhc2UsIGlzIGl0IGNvcnJlY3Q/DQo+ID4gPiA+PiA+ DQo+ID4gPiA+PiA+IFRoYXQgaXMgY29ycmVjdC4gVGhpcyBwYXRjaCBJIHJldmVydGVkIGludHJv ZHVjZXMgcmVncmVzc2lvbiBmb3IgcHJvZmVzc2lvbmFsDQo+ID4gPiA+PiA+IGxhcHRvcHMgdGhh dCBleHBlY3QgdGhlIExJRCBzd2l0Y2ggdG8gYmUgcmVwb3J0ZWQgYWNjdXJhdGVseS4NCj4gPiA+ ID4+DQo+ID4gPiA+PiBBbmQgZnJvbSBhIHVzZXIncyBwZXJzcGVjdGl2ZSwgd2hhdCBkb2VzIG5v dCB3b3JrIGFueSBtb3JlPw0KPiA+ID4gPg0KPiA+ID4gPiBJZiB5b3UgYm9vdCBvciByZXN1bWUg eW91ciBsYXB0b3Agd2l0aCB0aGUgbGlkIGNsb3NlZCBvbiBhIGRvY2tpbmcNCj4gPiA+ID4gc3Rh dGlvbiB3aGlsZSB1c2luZyBhbiBleHRlcm5hbCBtb25pdG9yIGNvbm5lY3RlZCB0byBpdCwgYm90 aCBpbnRlcm5hbA0KPiA+ID4gPiBhbmQgZXh0ZXJuYWwgZGlzcGxheXMgd2lsbCBsaWdodCBvbiwg d2hpbGUgb25seSB0aGUgZXh0ZXJuYWwgc2hvdWxkLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBp cyBhIGRlc2lnbiBjaG9pY2UgaW4gZ2RtIHRvIG9ubHkgcHJvdmlkZSB0aGUgZ3JlYXRlciBvbiB0 aGUNCj4gPiA+ID4gaW50ZXJuYWwgZGlzcGxheSB3aGVuIGxpdCBvbiwgc28gdXNlcnMgb25seSBz ZWUgYSBncmF5IGFyZWEgb24gdGhlDQo+ID4gPiA+IGV4dGVybmFsIG1vbml0b3IuIEFsc28sIHRo ZSBjdXJzb3Igd2lsbCBub3Qgc2hvdyB1cCBhcyBpdCdzIGJ5IGRlZmF1bHQNCj4gPiA+ID4gb24g dGhlIGludGVybmFsIGRpc3BsYXkgdG9vLg0KPiA+ID4gPg0KPiA+ID4gPiBUbyAiZml4IiB0aGF0 LCB1c2VycyBoYXZlIHRvIG9wZW4gdGhlIGxhcHRvcCBvbmNlIGFuZCBjbG9zZSBpdCBvbmNlDQo+ ID4gPiA+IGFnYWluIHRvIHN5bmMgdGhlIHN0YXRlIG9mIHRoZSBzd2l0Y2ggd2l0aCB0aGUgaGFy ZHdhcmUgc3RhdGUuDQo+ID4gPg0KPiA+ID4gT0sNCj4gPiA+DQo+ID4gPiBZZWFoLCB0aGF0IHN1 Y2tzLg0KPiA+ID4NCj4gPiA+IFNvIHdpdGhvdXQgdGhlIEx2J3MgcGF0Y2ggdGhlIGJlaGF2aW9y IChvbiB0aGUgc3lzdGVtcyBpbiBxdWVzdGlvbikgaXMNCj4gPiA+IGFzIGV4cGVjdGVkLCByaWdo dD8NCj4gPiA+DQo+ID4NCj4gPiBZZXMsIHJldmVydGluZyB0aGVzZSAyIHBhdGNoZXMgcmVzdG9y ZXMgdGhlIHByZSB2NC4xMSBrZXJuZWwgYmVoYXZpb3IuDQo+IA0KPiBJIHdvdWxkIG1ha2UgYW4g YXJndW1lbnQgdGhhdDoNCj4gQS4gSXMgdGhpcyBuZWNlc3NhcmlseSBhIGJ1dHRvbiBkcml2ZXIg cmVncmVzc2lvbj8NCj4gMS4gVXNlcnMgYWxyZWFkeSBjb25maWd1cmVkIHRvIG5vdCB1c2luZyBp bnRlcm5hbCBkaXNwbGF5LCB3aHkgZ2RtIG5lZWQgdG8gZGV0ZXJtaW5lIGl0IGFnYWluIGluc3Rl YWQNCj4gb2YgdXNlcnMgY2hvaWNlPw0KPiAyLiBDYW4gZ2RtL2dyYXBoaWNzIGRyaXZlciBzYXZl cyBzdGF0ZSBiZWZvcmUgc3VzcGVuZCwgYW5kIHJlc3RvcmVzIHNhdmVkIHN0YXRlIGFmdGVyIHJl c3VtZT8NCj4gICAgSWYgdXNlcnMgZGlkbid0IGNoYW5nZSBzdGF0ZSBkdXJpbmcgc3VzcGVuZCwg dGhlbiBldmVyeXRoaW5nIHNob3VsZCBiZSBjb3JyZWN0Lg0KPiAgICBJZiB1c2VycyBjaGFuZ2Vk IHN0YXRlIGR1cmluZyBzdXNwZW5kLCBpdCBzaG91bGQgYmUgYWNjZXB0YWJsZSBmb3IgdXNlcnMg dG8gY2hhbmdlIGl0IGFnYWluIHRvIG1ha2UNCj4gdGhlIHN0YXRlIGNvcnJlY3QuDQo+IFNlZSwg dGhpcyBpcyBvYnZpb3VzbHkgYSBjYXNlIHRoYXQgaXMgbm90IHNvIHN0cmljdGx5IHJlbGF0ZWQg dG8gQUNQSSBidXR0b24gZHJpdmVyLg0KPiBXaHkgZG8gd2UgbmVlZCB0byBmb3JjZSBidXR0b24g ZHJpdmVyIHRvIG1hcnJ5IGV4dGVybmFsIG1vbml0b3JzLg0KPiBCLiBCdWcgcmVwb3J0ZXJzIGFy ZSBhbGwgb2sgd2l0aCB1c2luZyBxdWlyayBtb2RlcyBhcyBib290IHBhcmFtZXRlcnMgdG8gd29y ayB0aGlzIGFyb3VuZC4NCj4gV2h5IHNob3VsZCB3ZSBjaGFuZ2Ugb3VyIGRlZmF1bHQgYmVoYXZp b3IgYWltbGVzc2x5Pw0KDQpJIGhhdmUgb25lIG1vcmUgY29uY2VybjoNCkluIGJ1dHRvbi5saWRf aW5pdF9zdGF0ZT1tZXRob2QgbW9kZSwNCklzIHRoYXQgcG9zc2libGUgZm9yIGxpYmlucHV0IHRv IHdvcmsgdGhpbmdzIGFyb3VuZCBpZiBfTElEIHJldHVybiB2YWx1ZSBpcyBub3QgY29ycmVjdD8N CkhvdyBsaWJpbnB1dCBlbnN1cmVzIGNvcnJlY3QgdGltaW5nIG9mIG92ZXJ3cml0aW5nIHRoZSBp bnB1dCBub2RlIHZhbHVlPw0KV2lsbCBidXR0b24gZHJpdmVyIGZha2VkIGV2ZW50IHZhbHVlIG92 ZXJ3cml0ZXMgd2hhdCBsaWJpbnB1dCBoYXMgd3JpdHRlbj8NCg0KRnJvbSB0aGlzIHBvaW50IG9m IHZpZXcsIGJ1dHRvbi5saWRfaW5pdF9zdGF0ZT1pZ25vcmUgbWlnaHQgYmUgYSBiZXR0ZXIgY2hv aWNlIHRoYW4gYnV0dG9uLmxpZF9pbml0X3N0YXRlPW1ldGhvZCB0byBhbGxvdyBsaWJpbnB1dCB0 byBkZWFsIHdpdGggYWxsIGtpbmQgb2YgY2FzZXMuDQoNClRoYW5rcyBhbmQgYmVzdCByZWdhcmRz DQpMdg0K -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On May 16 2017 or thereabouts, Zheng, Lv wrote: > Hi, > > > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-owner@vger.kernel.org] On Behalf Of Zheng, > > Lv > > Subject: RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > > > > Hi, Guys > > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open" > > > > > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > > > > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires > > > > <benjamin.tissoires@redhat.com> wrote: > > > > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > > > > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires > > > > >> <benjamin.tissoires@redhat.com> wrote: > > > > >> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote: > > > > >> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote: > > > > >> >> > Hi, > > > > >> >> > > > > > >> >> > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > > > > >> >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > > > lid_init_state=open" > > > > >> >> > > > > > > >> >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote: > > > > >> >> > > > Hi, > > > > >> >> > > > > > > > >> >> > > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] > > > > >> >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default behavior to > > > lid_init_state=open" > > > > >> >> > > > > > > > > >> >> > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. > > > > >> >> > > > > > > > > >> >> > > > > Even if the method implementation can be buggy on some platform, > > > > >> >> > > > > the "open" choice is worse. It breaks docking stations basically > > > > >> >> > > > > and there is no way to have a user-space hwdb to fix that. > > > > >> >> > > > > > > > > >> >> > > > > On the contrary, it's rather easy in user-space to have a hwdb > > > > >> >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can fix > > > > >> >> > > > > the state of the LID switch for us: you need to set the udev > > > > >> >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. > > > > >> >> > > > > > > > > >> >> > > > > When libinput detects internal keyboard events, it will > > > > >> >> > > > > overwrite the state of the switch to open, making it reliable > > > > >> >> > > > > again. Given that logind only checks the LID switch value after > > > > >> >> > > > > a timeout, we can assume the user will use the internal keyboard > > > > >> >> > > > > before this timeout expires. > > > > >> >> > > > > > > > > >> >> > > > > For example, such a hwdb entry is: > > > > >> >> > > > > > > > > >> >> > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > > > >> >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > > > > >> >> > > > > > > > >> > > > > > >> > [...] > > > > >> > > > > > >> >> > > > > >> >> Well, if it worked in a specific way that users depended on before the commit in > > > > >> >> question and now it works differently, then it does break things. > > > > >> >> > > > > >> >> Benjamin, my understanding is that this is the case, is it correct? > > > > >> > > > > > >> > That is correct. This patch I reverted introduces regression for professional > > > > >> > laptops that expect the LID switch to be reported accurately. > > > > >> > > > > >> And from a user's perspective, what does not work any more? > > > > > > > > > > If you boot or resume your laptop with the lid closed on a docking > > > > > station while using an external monitor connected to it, both internal > > > > > and external displays will light on, while only the external should. > > > > > > > > > > There is a design choice in gdm to only provide the greater on the > > > > > internal display when lit on, so users only see a gray area on the > > > > > external monitor. Also, the cursor will not show up as it's by default > > > > > on the internal display too. > > > > > > > > > > To "fix" that, users have to open the laptop once and close it once > > > > > again to sync the state of the switch with the hardware state. > > > > > > > > OK > > > > > > > > Yeah, that sucks. > > > > > > > > So without the Lv's patch the behavior (on the systems in question) is > > > > as expected, right? > > > > > > > > > > Yes, reverting these 2 patches restores the pre v4.11 kernel behavior. > > > > I would make an argument that: > > A. Is this necessarily a button driver regression? > > 1. Users already configured to not using internal display, why gdm need to determine it again instead > > of users choice? > > 2. Can gdm/graphics driver saves state before suspend, and restores saved state after resume? > > If users didn't change state during suspend, then everything should be correct. > > If users changed state during suspend, it should be acceptable for users to change it again to make > > the state correct. > > See, this is obviously a case that is not so strictly related to ACPI button driver. > > Why do we need to force button driver to marry external monitors. > > B. Bug reporters are all ok with using quirk modes as boot parameters to work this around. > > Why should we change our default behavior aimlessly? > > I have one more concern: > In button.lid_init_state=method mode, > Is that possible for libinput to work things around if _LID return value is not correct? > How libinput ensures correct timing of overwriting the input node value? > Will button driver faked event value overwrites what libinput has written? > > From this point of view, button.lid_init_state=ignore might be a better choice than button.lid_init_state=method to allow libinput to deal with all kind of cases. > This is my last email on this topic, I don't even want to fully read/answer the one in 1/2 given the amount of bad faith you put in that. This is a REGRESSION. It used to work on thousands of devices, it doesn't anymore. So any regression has to be chased down and no good reason can justify such a regression. The only solution is to revert both these changes. We can not ask user space to fix a kernel regression, it's not how it works. You can not also change the semantic of an input switch. An input switch, as per the input subsystem is supposed to forward an actual state of the underlying hardware. Any fake information is bad and has to be avoided. I already gave you 2 solutions to fix the 7 machines you see that are problematic, and you just seem to ignore them: - revert to the v4.10 behavior and let libinput fix that for you - revert to the v4.10 behavior and have a quirk database in acpi/button I also proposed to take maintainership on this particular module because you said you were assigned this by default because you were the last introducing changes in it. I asked you twice, and two times you replied skipping this part. It's clear you don't want to revert to the old state, and even if I can prove to you that you have to, you don't listen. So please, do not force me to call the maintainers and Linus on this simple 2 reverts. Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Benjamin > > > > > >> >> > > > > For example, such a hwdb entry is: > > > > > >> >> > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > > > > >> >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > > > > > >> >> Well, if it worked in a specific way that users depended on before the commit in > > > > > >> >> question and now it works differently, then it does break things. > > > > > >> >> Benjamin, my understanding is that this is the case, is it correct? > > > > > >> > That is correct. This patch I reverted introduces regression for professional > > > > > >> > laptops that expect the LID switch to be reported accurately. > > > > > >> And from a user's perspective, what does not work any more? > > > > > > If you boot or resume your laptop with the lid closed on a docking > > > > > > station while using an external monitor connected to it, both internal > > > > > > and external displays will light on, while only the external should. > > > > > > There is a design choice in gdm to only provide the greater on the > > > > > > internal display when lit on, so users only see a gray area on the > > > > > > external monitor. Also, the cursor will not show up as it's by default > > > > > > on the internal display too. > > > > > > To "fix" that, users have to open the laptop once and close it once > > > > > > again to sync the state of the switch with the hardware state. > > > > > OK > > > > > Yeah, that sucks. > > > > > So without the Lv's patch the behavior (on the systems in question) is > > > > > as expected, right? > > > > Yes, reverting these 2 patches restores the pre v4.11 kernel behavior. > > > I would make an argument that: > > > A. Is this necessarily a button driver regression? > > > 1. Users already configured to not using internal display, why gdm need to determine it again > instead > > > of users choice? > > > 2. Can gdm/graphics driver saves state before suspend, and restores saved state after resume? > > > If users didn't change state during suspend, then everything should be correct. > > > If users changed state during suspend, it should be acceptable for users to change it again to > make > > > the state correct. > > > See, this is obviously a case that is not so strictly related to ACPI button driver. > > > Why do we need to force button driver to marry external monitors. > > > B. Bug reporters are all ok with using quirk modes as boot parameters to work this around. > > > Why should we change our default behavior aimlessly? > > > > I have one more concern: > > In button.lid_init_state=method mode, > > Is that possible for libinput to work things around if _LID return value is not correct? > > How libinput ensures correct timing of overwriting the input node value? > > Will button driver faked event value overwrites what libinput has written? > > > > From this point of view, button.lid_init_state=ignore might be a better choice than > button.lid_init_state=method to allow libinput to deal with all kind of cases. > > > > This is my last email on this topic, I don't even want to fully read/answer > the one in 1/2 given the amount of bad faith you put in that. What's that? I mean, the bad faith? > This is a REGRESSION. It used to work on thousands of devices, it > doesn't anymore. So any regression has to be chased down and no good > reason can justify such a regression. I triggered many such kind of layered regressions and did fix them 1 by 1 in different places. However, this might be different. Which depends on our agreement. > The only solution is to revert both these changes. We can not ask user > space to fix a kernel regression, it's not how it works. Yes, I know. We just asked users to use quirk modes of button driver. And there is in fact always one of them working. We haven't asked user space to change. We are just discussing the correctness of some user space behaviors. > You can not also change the semantic of an input switch. An input > switch, as per the input subsystem is supposed to forward an actual > state of the underlying hardware. Any fake information is bad and has to > be avoided. Since fake events are harmful, why do we fake an event after boot/resume? button.lid_init_state=method seems can fake such an event. > I already gave you 2 solutions to fix the 7 machines you see that are > problematic, and you just seem to ignore them: > - revert to the v4.10 behavior and let libinput fix that for you I already chose this. But I just raised a concern that button.lid_init_state=method could bring troubles to libinput quirks. > - revert to the v4.10 behavior and have a quirk database in acpi/button > > I also proposed to take maintainership on this particular module because > you said you were assigned this by default because you were the last > introducing changes in it. I asked you twice, and two times you replied > skipping this part. I didn't, you just skipped PATCH 1/2 reply... Let me copy it from that email: ===== Actually there is no special maintainership related to the button driver. All drivers of ACPI spec defined devices (PNPxxx stuffs) are maintained as a whole by Rafael. And we are helping him by doing triage on kernel Bugzilla. There isn't a category on kernel Bugzilla related to lid issues. Probably you can help to create one under ACPI product. If this can be achieved, you can be the default assignee for such issues. If this cannot be achieved, we'll just forward some lid reports to you first. Please tell me which product/component you'd prefer for us to forward. For modifying acpi/button.c, it's open source, you can send patches and ACPI community can help to review. ===== > It's clear you don't want to revert to the old state, and even if I can > prove to you that you have to, you don't listen. > So please, do not force me to call the maintainers and Linus on this > simple 2 reverts. No, I currently cannot persuade myself to revert to "method" mode. But that doesn't mean I don't want to or I want to. You just didn't prove that by answering my questions in PATCH 1/2 and in this email. Especially: 1. After reverting to "method" mode, can libinput work all cases around? Are there any timing issues that can prevent libinput from working some sucks around. Considering this case, it's likely such problems can happen. https://bugzilla.kernel.org/show_bug.cgi?id=106151 2. Who should be responsible for fixing this issue after reverting to "method" mode: https://bugzilla.kernel.org/show_bug.cgi?id=106151 What's the root cause of this issue? 3. How can we generate the quirk for the following possible breakage: No lid notification and _LID return cached open after boot/resume Cheers, Lv
On May 16 2017 or thereabouts, Zheng, Lv wrote: > Hi, Benjamin > > > > > > > >> >> > > > > For example, such a hwdb entry is: > > > > > > >> >> > > > > libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* > > > > > > >> >> > > > > LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open > > > > > > >> >> Well, if it worked in a specific way that users depended on before the commit in > > > > > > >> >> question and now it works differently, then it does break things. > > > > > > >> >> Benjamin, my understanding is that this is the case, is it correct? > > > > > > >> > That is correct. This patch I reverted introduces regression for professional > > > > > > >> > laptops that expect the LID switch to be reported accurately. > > > > > > >> And from a user's perspective, what does not work any more? > > > > > > > If you boot or resume your laptop with the lid closed on a docking > > > > > > > station while using an external monitor connected to it, both internal > > > > > > > and external displays will light on, while only the external should. > > > > > > > There is a design choice in gdm to only provide the greater on the > > > > > > > internal display when lit on, so users only see a gray area on the > > > > > > > external monitor. Also, the cursor will not show up as it's by default > > > > > > > on the internal display too. > > > > > > > To "fix" that, users have to open the laptop once and close it once > > > > > > > again to sync the state of the switch with the hardware state. > > > > > > OK > > > > > > Yeah, that sucks. > > > > > > So without the Lv's patch the behavior (on the systems in question) is > > > > > > as expected, right? > > > > > Yes, reverting these 2 patches restores the pre v4.11 kernel behavior. > > > > I would make an argument that: > > > > A. Is this necessarily a button driver regression? > > > > 1. Users already configured to not using internal display, why gdm need to determine it again > > instead > > > > of users choice? > > > > 2. Can gdm/graphics driver saves state before suspend, and restores saved state after resume? > > > > If users didn't change state during suspend, then everything should be correct. > > > > If users changed state during suspend, it should be acceptable for users to change it again to > > make > > > > the state correct. > > > > See, this is obviously a case that is not so strictly related to ACPI button driver. > > > > Why do we need to force button driver to marry external monitors. > > > > B. Bug reporters are all ok with using quirk modes as boot parameters to work this around. > > > > Why should we change our default behavior aimlessly? > > > > > > I have one more concern: > > > In button.lid_init_state=method mode, > > > Is that possible for libinput to work things around if _LID return value is not correct? > > > How libinput ensures correct timing of overwriting the input node value? > > > Will button driver faked event value overwrites what libinput has written? > > > > > > From this point of view, button.lid_init_state=ignore might be a better choice than > > button.lid_init_state=method to allow libinput to deal with all kind of cases. > > > > > > > This is my last email on this topic, I don't even want to fully read/answer > > the one in 1/2 given the amount of bad faith you put in that. > > What's that? > I mean, the bad faith? I already explained 4 times why we need to revert these two patches and why we need to keep 'method'. And you keep answering with long emails that you would rather not. I call it bad faith, sorry. > > > This is a REGRESSION. It used to work on thousands of devices, it > > doesn't anymore. So any regression has to be chased down and no good > > reason can justify such a regression. > > I triggered many such kind of layered regressions and did fix them 1 by 1 in different places. > However, this might be different. No. It is a regression. It used to work for thousands of devices befor v4.11, and now it's broken for those devices. It's a regression. Some new devices are broken with "method", it's a bug, and we can't fix them by regressing on all the others. > Which depends on our agreement. > > > The only solution is to revert both these changes. We can not ask user > > space to fix a kernel regression, it's not how it works. > > Yes, I know. > We just asked users to use quirk modes of button driver. I call this "fixing by users", and this is wrong. It used to work for years for almost everybody, you can not ask users to fix this one by one. > And there is in fact always one of them working. Yes, it's called a quirk. And the good practice is to register those quirks and make them available to everybody. Being in hwdb in user space or in acpi/button in kernel space doesn't matter, we need them. > We haven't asked user space to change. > We are just discussing the correctness of some user space behaviors. They *are* correct. They are following the exported ACPI documentation and the input node documentation. Quoting the input doc: file Documentation/input/event-codes.rst: EV_SW ----- EV_SW events describe stateful binary switches. For example, the SW_LID code is used to denote when a laptop lid is closed. Upon binding to a device or resuming from suspend, a driver must report the current switch state. This ensures that the device, kernel, and userspace state is in sync. Upon resume, if the switch state is the same as before suspend, then the input subsystem will filter out the duplicate switch state reports. The driver does not need to keep the state of the switch at any time. ---- So no, you can't have 'ignore' or 'open' to be the default, because user space expects the switch to reflect the current state of the hardware. > > > You can not also change the semantic of an input switch. An input > > switch, as per the input subsystem is supposed to forward an actual > > state of the underlying hardware. Any fake information is bad and has to > > be avoided. > > Since fake events are harmful, why do we fake an event after boot/resume? > button.lid_init_state=method seems can fake such an event. We don't fake an event, we are syncing the input switch state with the hardware. Faking an event is when you send "switch is open" while you know there is a possibility it's actually closed. > > > I already gave you 2 solutions to fix the 7 machines you see that are > > problematic, and you just seem to ignore them: > > - revert to the v4.10 behavior and let libinput fix that for you > > I already chose this. > But I just raised a concern that button.lid_init_state=method could bring troubles to libinput quirks. No. We can do whatever we want in libinput. And we can fix hardware when it appears. We don't need to have the correct solution for everybody, ever. libinput is a library and it can be updated, and we can ask users to upgrade. We can even break the API by bumping the soname. We have much more liberty that the kernel has, so the libinput implementation shouldn't be a concern. > > > - revert to the v4.10 behavior and have a quirk database in acpi/button > > > > I also proposed to take maintainership on this particular module because > > you said you were assigned this by default because you were the last > > introducing changes in it. I asked you twice, and two times you replied > > skipping this part. > > I didn't, you just skipped PATCH 1/2 reply... > Let me copy it from that email: > ===== > Actually there is no special maintainership related to the button driver. > All drivers of ACPI spec defined devices (PNPxxx stuffs) are maintained as a whole by Rafael. I know, but there is the file MAINTAINER where you can add individual maintainer per file. Rafael will still be the ACPI maintainer, providing PR to Linus, but I'll just be the other goto-guy when people run get_maintainer.pl on the acpi/button file. > And we are helping him by doing triage on kernel Bugzilla. > > There isn't a category on kernel Bugzilla related to lid issues. > Probably you can help to create one under ACPI product. That would be good to have such a category (maybe not LID, but input or button to reflect the file name) > If this can be achieved, you can be the default assignee for such issues. > If this cannot be achieved, we'll just forward some lid reports to you first. Please do. > Please tell me which product/component you'd prefer for us to forward. I'd be happy to be redirected anything input related. > > For modifying acpi/button.c, it's open source, you can send patches and ACPI community can help to review. Which I already did. My concern is more when there is a change I am not aware of which introduces regressions and which I could have provided a valid NACK early enough. > ===== > > > It's clear you don't want to revert to the old state, and even if I can > > prove to you that you have to, you don't listen. > > So please, do not force me to call the maintainers and Linus on this > > simple 2 reverts. > > No, I currently cannot persuade myself to revert to "method" mode. > But that doesn't mean I don't want to or I want to. > You just didn't prove that by answering my questions in PATCH 1/2 and in this email. > Especially: > 1. After reverting to "method" mode, can libinput work all cases around? If it doesn't, we'll fix it. So yes, it will eventually. > Are there any timing issues that can prevent libinput from working some sucks around. > Considering this case, it's likely such problems can happen. > https://bugzilla.kernel.org/show_bug.cgi?id=106151 logind has a delay between the time it starts and the time it starts polling the lid switch state. The default value is a little bit too short on Fedora considering the faulty devices are running small CPUs. But this can be changed as wish by the user and by systemd. They told us they took one arbitrary value by default, and we can change it. We can ask systemd/logind to change part of the behavior for new devices when there is a bug. But we can't ask them to change the whole design because there is a regression in the kernel. > 2. Who should be responsible for fixing this issue after reverting to "method" mode: > https://bugzilla.kernel.org/show_bug.cgi?id=106151 libinput will change the value to open given the heuristics we have. > What's the root cause of this issue? Poorly written EC? It doesn't matter. We know the machine is buggy, we'll just need a workaround. > 3. How can we generate the quirk for the following possible breakage: > No lid notification and _LID return cached open after boot/resume "method" will fetch and report the cached _LID value as open, so there is no breakage. Unless the lid is actually closed and the EC is plain wrong, but that is something we can also explain to users or fix by an other mean. But nothing generic will work. For instance, on the Surface 3, the LID notification for open isn't forwarded, so I wrote a specific driver to get the correct behavior based on a careful analysis of the DSDT. Cheers, Benjamin > > Cheers, > Lv -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
SGksIEJlbmphbWluDQoNCj4gPiBXaGF0J3MgdGhhdD8NCj4gPiBJIG1lYW4sIHRoZSBiYWQgZmFp dGg/DQo+IEkgYWxyZWFkeSBleHBsYWluZWQgNCB0aW1lcyB3aHkgd2UgbmVlZCB0byByZXZlcnQg dGhlc2UgdHdvIHBhdGNoZXMgYW5kDQo+IHdoeSB3ZSBuZWVkIHRvIGtlZXAgJ21ldGhvZCcuIEFu ZCB5b3Uga2VlcCBhbnN3ZXJpbmcgd2l0aCBsb25nIGVtYWlscw0KPiB0aGF0IHlvdSB3b3VsZCBy YXRoZXIgbm90LiBJIGNhbGwgaXQgYmFkIGZhaXRoLCBzb3JyeS4NCg0KVGhlIDQgdGltZXMgZXhw bGFuYXRpb25zIGRpZG4ndCBhbnN3ZXIgbXkgcXVlc3Rpb25zLg0KQnV0IHRoYXQncyBPSywgbGV0 J3MgY2xhcmlmeSBpdCBhZ2Fpbi4NCg0KPiA+ID4gVGhpcyBpcyBhIFJFR1JFU1NJT04uIEl0IHVz ZWQgdG8gd29yayBvbiB0aG91c2FuZHMgb2YgZGV2aWNlcywgaXQNCj4gPiA+IGRvZXNuJ3QgYW55 bW9yZS4gU28gYW55IHJlZ3Jlc3Npb24gaGFzIHRvIGJlIGNoYXNlZCBkb3duIGFuZCBubyBnb29k DQo+ID4gPiByZWFzb24gY2FuIGp1c3RpZnkgc3VjaCBhIHJlZ3Jlc3Npb24uDQo+ID4gSSB0cmln Z2VyZWQgbWFueSBzdWNoIGtpbmQgb2YgbGF5ZXJlZCByZWdyZXNzaW9ucyBhbmQgZGlkIGZpeCB0 aGVtIDEgYnkgMSBpbiBkaWZmZXJlbnQgcGxhY2VzLg0KPiA+IEhvd2V2ZXIsIHRoaXMgbWlnaHQg YmUgZGlmZmVyZW50Lg0KPiBOby4gSXQgaXMgYSByZWdyZXNzaW9uLiBJdCB1c2VkIHRvIHdvcmsg Zm9yIHRob3VzYW5kcyBvZiBkZXZpY2VzIGJlZm9yDQo+IHY0LjExLCBhbmQgbm93IGl0J3MgYnJv a2VuIGZvciB0aG9zZSBkZXZpY2VzLiBJdCdzIGEgcmVncmVzc2lvbi4NCj4gU29tZSBuZXcgZGV2 aWNlcyBhcmUgYnJva2VuIHdpdGggIm1ldGhvZCIsIGl0J3MgYSBidWcsIGFuZCB3ZSBjYW4ndCBm aXgNCj4gdGhlbSBieSByZWdyZXNzaW5nIG9uIGFsbCB0aGUgb3RoZXJzLg0KLi4uDQo+IEkgY2Fs bCB0aGlzICJmaXhpbmcgYnkgdXNlcnMiLCBhbmQgdGhpcyBpcyB3cm9uZy4gSXQgdXNlZCB0byB3 b3JrIGZvcg0KPiB5ZWFycyBmb3IgYWxtb3N0IGV2ZXJ5Ym9keSwgeW91IGNhbiBub3QgYXNrIHVz ZXJzIHRvIGZpeCB0aGlzIG9uZSBieQ0KPiBvbmUuDQoNCldoYXQgYWJvdXQgcmVncmVzc2lvbnMg dHJpZ2dlcmVkIGJ5IHRoaXMgY29tbWl0Og0KaHR0cHM6Ly9naXQua2VybmVsLm9yZy9wdWIvc2Nt L2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L2NvbW1pdC8/aWQ9MjNkZTVkOWVm MmE0DQpCZWZvcmUgdGhhdCAoeWVhciAyMDA3KSwgImlnbm9yZSIgaXMgdGhlIGRlZmF1bHQgbW9k ZS4NCg0KT3RoZXIgdGhhbiB0aGlzLCBJIGp1c3QgaGFkIGNvbmNlcm5zIHJlbGF0ZWQgdG8gZml4 aW5nIHRoaW5ncyBiYWNrIGFuZCBmb3J0aCwgYnV0IHlvdSBkaWRuJ3QgcmVwbHkgcHJvcGVybHku DQpBZ2FpbiwgdGhhdCdzIE9LLCBsZXQncyBqdXN0IGNsYXJpZnkgaXQuDQoNCj4gWWVzLCBpdCdz IGNhbGxlZCBhIHF1aXJrLiBBbmQgdGhlIGdvb2QgcHJhY3RpY2UgaXMgdG8gcmVnaXN0ZXIgdGhv c2UNCj4gcXVpcmtzIGFuZCBtYWtlIHRoZW0gYXZhaWxhYmxlIHRvIGV2ZXJ5Ym9keS4gQmVpbmcg aW4gaHdkYiBpbiB1c2VyIHNwYWNlDQo+IG9yIGluIGFjcGkvYnV0dG9uIGluIGtlcm5lbCBzcGFj ZSBkb2Vzbid0IG1hdHRlciwgd2UgbmVlZCB0aGVtLg0KDQpJIGhhdmUgbm8gb2JqZWN0aW9ucyBi dXQgY29uY2VybnMgcmVsYXRlZCB0byB0aGUgY29tYmluYXRpb24gb2YgImRlZmF1bHQgbW9kZSIg YW5kICJxdWlyayByZXNwb25zaWJsZXMiLg0KRnJvbSBteSBwb2ludCBvZiB2aWV3LCB0aGVzZSBh cmUgbXkgY29uY2x1c2lvbnM6DQoxLiBJZiB5b3Ugd2FudCB0byB1c2UgbGliaW5wdXQgdG8gZ2Vu ZXJhdGUgcXVpcmtzLCB5b3Ugc2hvdWxkIHVzZSAiaWdub3JlIiByYXRoZXIgdGhhbiAibWV0aG9k IiBtb2RlIGFzIGRlZmF1bHQgbW9kZTsNCjIuIElmIHlvdSB3YW50IHRvIHVzZSBidXR0b24gZHJp dmVyIHRvIGdlbmVyYXRlIHF1aXJrcywgd2UgbmVlZCAiY2xvc2UiIG1vZGU7DQozLiBJZiBHRE0g Y2FuIGNoYW5nZSBvciB1c2VycyBhcmUgb2sgdXNlIGNvbW1hbmQgbGluZXMsIHdlIGNhbiByZW1h aW4gdG8gdXNlICJvcGVuIiBhcyB0aGUgZGVmYXVsdCBiZWhhdmlvci4NCihJJ2xsIHNlbmQgdGVj aG5pY2FsIGRldGFpbHMgaW4gcHJpdmF0ZSBhYm91dCB0aGVzZSBjb25jbHVzaW9ucykNCkJ1dCB5 b3Ugc2VlbSB0byBhbHdheXM6DQoxLiBTYXkgbm8gdG8gImlnbm9yZSIgd2hpY2ggbWFrZXMgMSBp bXBvc3NpYmxlOw0KMi4gU2F5IG5vIHRvICJjbG9zZSIgd2hpY2ggbWFrZXMgMiBpbXBvc3NpYmxl Ow0KMy4gU2F5IG5vIHRvICJvcGVuIiB3aGljaCBtYWtlcyAzIGltcG9zc2libGUuDQoNCj4gPiBX ZSBoYXZlbid0IGFza2VkIHVzZXIgc3BhY2UgdG8gY2hhbmdlLg0KPiA+IFdlIGFyZSBqdXN0IGRp c2N1c3NpbmcgdGhlIGNvcnJlY3RuZXNzIG9mIHNvbWUgdXNlciBzcGFjZSBiZWhhdmlvcnMuDQo+ IA0KPiBUaGV5ICphcmUqIGNvcnJlY3QuDQo+IFRoZXkgYXJlIGZvbGxvd2luZyB0aGUgZXhwb3J0 ZWQgQUNQSSBkb2N1bWVudGF0aW9uDQoNCkkgZG91YnQuIEluIEFDUEkgd29ybGQsIFdpbmRvd3Mg aXMgdGhlIG9ubHkgc3RhbmRhcmQuDQoNCj4gYW5kIHRoZSBpbnB1dCBub2RlIGRvY3VtZW50YXRp b24uDQo+IFF1b3RpbmcgdGhlIGlucHV0IGRvYzoNCj4gZmlsZSBEb2N1bWVudGF0aW9uL2lucHV0 L2V2ZW50LWNvZGVzLnJzdDoNCj4gRVZfU1cNCj4gLS0tLS0NCj4gDQo+IEVWX1NXIGV2ZW50cyBk ZXNjcmliZSBzdGF0ZWZ1bCBiaW5hcnkgc3dpdGNoZXMuIEZvciBleGFtcGxlLCB0aGUgU1dfTElE IGNvZGUgaXMNCj4gdXNlZCB0byBkZW5vdGUgd2hlbiBhIGxhcHRvcCBsaWQgaXMgY2xvc2VkLg0K PiANCj4gVXBvbiBiaW5kaW5nIHRvIGEgZGV2aWNlIG9yIHJlc3VtaW5nIGZyb20gc3VzcGVuZCwg YSBkcml2ZXIgbXVzdCByZXBvcnQNCj4gdGhlIGN1cnJlbnQgc3dpdGNoIHN0YXRlLiBUaGlzIGVu c3VyZXMgdGhhdCB0aGUgZGV2aWNlLCBrZXJuZWwsIGFuZCB1c2Vyc3BhY2UNCj4gc3RhdGUgaXMg aW4gc3luYy4NCj4gDQo+IFVwb24gcmVzdW1lLCBpZiB0aGUgc3dpdGNoIHN0YXRlIGlzIHRoZSBz YW1lIGFzIGJlZm9yZSBzdXNwZW5kLCB0aGVuIHRoZSBpbnB1dA0KPiBzdWJzeXN0ZW0gd2lsbCBm aWx0ZXIgb3V0IHRoZSBkdXBsaWNhdGUgc3dpdGNoIHN0YXRlIHJlcG9ydHMuIFRoZSBkcml2ZXIg ZG9lcw0KPiBub3QgbmVlZCB0byBrZWVwIHRoZSBzdGF0ZSBvZiB0aGUgc3dpdGNoIGF0IGFueSB0 aW1lLg0KPiAtLS0tDQoNClRoYXQncyByZWFsbHkgYSBjb252ZW5pZW50IGZlYXR1cmUgZm9yIGRy aXZlci4NCklmIEknbSB0aGUgZHJpdmVyIHdyaXRlcnMsIEkgd291bGQgYmUgdmVyeSBhcHByZWNp YXRlZCBmb3IgYmVpbmcgYWJsZSB0byB1c2Ugc3VjaCBmZWF0dXJlcy4NClNvIHlvdSBzZWUgSSBk b24ndCBoYXZlIG9iamVjdGlvbnMgdG8gaGF2aW5nIHRoaXMgZmVhdHVyZS4NCg0KSSBqdXN0IGhh dmUgY29uY2VybnMgcmVsYXRlZCB0bzoNCjEuIElzIGl0IHJlcXVpcmVkIHRvIGhhdmUgYSB0aW1l b3V0IGluIHN5c3RlbWQsIGZvcmNpbmcgcGxhdGZvcm0gdG8gc3VzcGVuZCBhZ2FpbiwganVzdCBk dWUgdG8gZXZlbnQgZGVsYXlzPw0KMi4gSXMgaXQgcmVxdWlyZWQgdG8gdXNlIFNXX0xJRCB0byBk ZXRlcm1pbmUgd2hldGhlciBhbiBpbnRlcm5hbCBkaXNwbGF5IHNob3VsZCBiZSBsaXQgb24/DQpJ IGRvbid0IHNlZSBhbnkgY29uZmxpY3RzIGJldHdlZW4gdGhlIEFCSSBvZiBFVl9TVyBhbmQgdGhl IDIgcXVlc3Rpb25zLg0KDQo+IFNvIG5vLCB5b3UgY2FuJ3QgaGF2ZSAnaWdub3JlJyBvciAnb3Bl bicgdG8gYmUgdGhlIGRlZmF1bHQsIGJlY2F1c2UgdXNlcg0KPiBzcGFjZSBleHBlY3RzIHRoZSBz d2l0Y2ggdG8gcmVmbGVjdCB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgaGFyZHdhcmUuDQoNClRo ZW4gd2hhdCdzIHRoZSBiZW5lZml0IG9mIGhhdmluZyAnbWV0aG9kJyB0byBiZSB0aGUgZGVmYXVs dCwNCkdpdmVuIGl0IGlzIHN0aWxsIG5vdCBhYmxlIHRvIHJlbGlhYmx5IGRlbGl2ZXIgdGhlIGN1 cnJlbnQgc3RhdGUgb2YgaGFyZHdhcmU/DQpBY3R1YWxseSBib3RoICdpZ25vcmUvb3Blbi9tZXRo b2QnIG1vZGVzIGFyZSB0cnlpbmcgdG8gYmUgY29tcGxpYW50IHRvIEVWX1NXLg0KQW1vbmcgdGhl bSwgImlnbm9yZSIgZGlkIHRoZSBiZXN0IElNTy4NCkFuZCBjYXNlcyBicm9rZW4gaW4gImlnbm9y ZSIgbW9kZSBidXQgbm90IGJyb2tlbiBpbiAibWV0aG9kIiBtb2RlIGFyZSBhbGwgaXNzdWVzOg0K IC0gUGxhdGZvcm0gZG9lc24ndCBzZW5kIG5vdGlmaWNhdGlvbiBhZnRlciBib290L3Jlc3VtZS4N CiAgIElNTywgd2Ugc2hvdWxkIGFsc28gY29sbGVjdCB0aGVtIGFuZCBpbmRpY2F0ZSB0aGVtIHRv IGRlc2t0b3AgbWFuYWdlcnMuDQoNClNvIGluIHRoZSBlbmQsIHdlIGp1c3QgaGF2ZSBkaWZmZXJl bmNlcyByZWxhdGVkIHRvIHBpY2tpbmcgd2hpY2ggZGVmYXVsdCBtb2RlLg0KDQo+ID4gPiBZb3Ug Y2FuIG5vdCBhbHNvIGNoYW5nZSB0aGUgc2VtYW50aWMgb2YgYW4gaW5wdXQgc3dpdGNoLiBBbiBp bnB1dA0KPiA+ID4gc3dpdGNoLCBhcyBwZXIgdGhlIGlucHV0IHN1YnN5c3RlbSBpcyBzdXBwb3Nl ZCB0byBmb3J3YXJkIGFuIGFjdHVhbA0KPiA+ID4gc3RhdGUgb2YgdGhlIHVuZGVybHlpbmcgaGFy ZHdhcmUuIEFueSBmYWtlIGluZm9ybWF0aW9uIGlzIGJhZCBhbmQgaGFzIHRvDQo+ID4gPiBiZSBh dm9pZGVkLg0KPiA+IFNpbmNlIGZha2UgZXZlbnRzIGFyZSBoYXJtZnVsLCB3aHkgZG8gd2UgZmFr ZSBhbiBldmVudCBhZnRlciBib290L3Jlc3VtZT8NCj4gPiBidXR0b24ubGlkX2luaXRfc3RhdGU9 bWV0aG9kIHNlZW1zIGNhbiBmYWtlIHN1Y2ggYW4gZXZlbnQuDQo+IFdlIGRvbid0IGZha2UgYW4g ZXZlbnQsIHdlIGFyZSBzeW5jaW5nIHRoZSBpbnB1dCBzd2l0Y2ggc3RhdGUgd2l0aCB0aGUNCj4g aGFyZHdhcmUuDQo+IEZha2luZyBhbiBldmVudCBpcyB3aGVuIHlvdSBzZW5kICJzd2l0Y2ggaXMg b3BlbiIgd2hpbGUgeW91IGtub3cgdGhlcmUNCj4gaXMgYSBwb3NzaWJpbGl0eSBpdCdzIGFjdHVh bGx5IGNsb3NlZC4NCg0KTm8gd2UgYXJlIGZha2luZyBldmVudHMgaW4gdGhpcyBtb2RlLg0KX0xJ RCBjYW4gcmV0dXJuIGNhY2hlZCBzdGF0ZSwgYW5kOg0KMS4gaXQgbWlnaHQgYmUgImNsb3NlIiB3 aGlsZSBMSUQgaXMgIm9wZW4iIGFmdGVyIHN1c3BlbmQuDQoyLiBpdCBtaWdodCBiZSAib3BlbiIg d2hpbGUgTElEIGlzICJjbG9zZSIgYWZ0ZXIgc3VzcGVuZC4NCkluIHRoaXMgY2FzZSwgaXQgZXhw bGFpbnMgdGhlIHNpZGUgZWZmZWN0IG9mIGhhdmluZyB0eXBlIDEgZmFrZSBldmVudDoNCmh0dHBz Oi8vYnVnemlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MTA2MTUxDQpJZiB3ZSBkb24n dCBldmFsdWF0ZSBfTElEIGFuZCBzZW5kIHN1Y2ggYSAiY2xvc2UiLCB0aGUgcGxhdGZvcm0gY2Fu IGNvcnJlY3RseSBzZW5kICJvcGVuIiBqdXN0IHdpdGggYSBkZWxheS4NCg0KPiA+ID4gSSBhbHJl YWR5IGdhdmUgeW91IDIgc29sdXRpb25zIHRvIGZpeCB0aGUgNyBtYWNoaW5lcyB5b3Ugc2VlIHRo YXQgYXJlDQo+ID4gPiBwcm9ibGVtYXRpYywgYW5kIHlvdSBqdXN0IHNlZW0gdG8gaWdub3JlIHRo ZW06DQo+ID4gPiAtIHJldmVydCB0byB0aGUgdjQuMTAgYmVoYXZpb3IgYW5kIGxldCBsaWJpbnB1 dCBmaXggdGhhdCBmb3IgeW91DQo+ID4NCj4gPiBJIGFscmVhZHkgY2hvc2UgdGhpcy4NCj4gPiBC dXQgSSBqdXN0IHJhaXNlZCBhIGNvbmNlcm4gdGhhdCBidXR0b24ubGlkX2luaXRfc3RhdGU9bWV0 aG9kIGNvdWxkIGJyaW5nIHRyb3VibGVzIHRvIGxpYmlucHV0DQo+IHF1aXJrcy4NCj4gDQo+IE5v LiBXZSBjYW4gZG8gd2hhdGV2ZXIgd2Ugd2FudCBpbiBsaWJpbnB1dC4gQW5kIHdlIGNhbiBmaXgg aGFyZHdhcmUgd2hlbg0KPiBpdCBhcHBlYXJzLiBXZSBkb24ndCBuZWVkIHRvIGhhdmUgdGhlIGNv cnJlY3Qgc29sdXRpb24gZm9yIGV2ZXJ5Ym9keSwNCj4gZXZlci4gbGliaW5wdXQgaXMgYSBsaWJy YXJ5IGFuZCBpdCBjYW4gYmUgdXBkYXRlZCwgYW5kIHdlIGNhbiBhc2sgdXNlcnMNCj4gdG8gdXBn cmFkZS4gV2UgY2FuIGV2ZW4gYnJlYWsgdGhlIEFQSSBieSBidW1waW5nIHRoZSBzb25hbWUuIFdl IGhhdmUNCj4gbXVjaCBtb3JlIGxpYmVydHkgdGhhdCB0aGUga2VybmVsIGhhcywgc28gdGhlIGxp YmlucHV0IGltcGxlbWVudGF0aW9uDQo+IHNob3VsZG4ndCBiZSBhIGNvbmNlcm4uDQoNCkl0IHNl ZW1zIHlvdSBkb24ndCBrbm93IGFsbCB0aGUgZGV0YWlscyBJIHdhcyBsb29raW5nIGF0Lg0KSXQn cyBhYm91dCBhIHRpbWluZyBwcm9ibGVtLCB3aXRoIGJ1dHRvbi5saWRfaW5pdF9zdGF0ZT1tZXRo b2QgYW5kIGxpYmlucHV0IHF1aXJrLCB3ZSBhY3R1YWxseSBoYXZlIDIgcXVpcmtzLg0KQW5kIGxp YmlucHV0IHdyaXRlIGNhbiBhcHBlYXIgYmVmb3JlL2FmdGVyIHRoZSBmYWtlZCBpbml0IG5vdGlm aWNhdGlvbiB0cmlnZ2VyZWQgYnkgIm1ldGhvZCIgbW9kZS4NCkNhdXNpbmcgc29tZSBjYXNlcyBu b3Qgd29ya2Fyb3VuZGFibGUuDQpTZWUgYmVsb3cgZm9yIGRldGFpbHMuDQoNCj4gPiBObywgSSBj dXJyZW50bHkgY2Fubm90IHBlcnN1YWRlIG15c2VsZiB0byByZXZlcnQgdG8gIm1ldGhvZCIgbW9k ZS4NCj4gPiBCdXQgdGhhdCBkb2Vzbid0IG1lYW4gSSBkb24ndCB3YW50IHRvIG9yIEkgd2FudCB0 by4NCj4gPiBZb3UganVzdCBkaWRuJ3QgcHJvdmUgdGhhdCBieSBhbnN3ZXJpbmcgbXkgcXVlc3Rp b25zIGluIFBBVENIIDEvMiBhbmQgaW4gdGhpcyBlbWFpbC4NCj4gPiBFc3BlY2lhbGx5Og0KPiA+ IDEuIEFmdGVyIHJldmVydGluZyB0byAibWV0aG9kIiBtb2RlLCBjYW4gbGliaW5wdXQgd29yayBh bGwgY2FzZXMgYXJvdW5kPw0KPiBJZiBpdCBkb2Vzbid0LCB3ZSdsbCBmaXggaXQuIFNvIHllcywg aXQgd2lsbCBldmVudHVhbGx5Lg0KDQpUaGF0J3MgZ3JlYXQuDQoNCj4gPiAgICBBcmUgdGhlcmUg YW55IHRpbWluZyBpc3N1ZXMgdGhhdCBjYW4gcHJldmVudCBsaWJpbnB1dCBmcm9tIHdvcmtpbmcg c29tZSBzdWNrcyBhcm91bmQuDQo+ID4gICAgQ29uc2lkZXJpbmcgdGhpcyBjYXNlLCBpdCdzIGxp a2VseSBzdWNoIHByb2JsZW1zIGNhbiBoYXBwZW4uDQo+ID4gICAgaHR0cHM6Ly9idWd6aWxsYS5r ZXJuZWwub3JnL3Nob3dfYnVnLmNnaT9pZD0xMDYxNTENCj4gDQo+IGxvZ2luZCBoYXMgYSBkZWxh eSBiZXR3ZWVuIHRoZSB0aW1lIGl0IHN0YXJ0cyBhbmQgdGhlIHRpbWUgaXQgc3RhcnRzDQo+IHBv bGxpbmcgdGhlIGxpZCBzd2l0Y2ggc3RhdGUuIFRoZSBkZWZhdWx0IHZhbHVlIGlzIGEgbGl0dGxl IGJpdCB0b28NCj4gc2hvcnQgb24gRmVkb3JhIGNvbnNpZGVyaW5nIHRoZSBmYXVsdHkgZGV2aWNl cyBhcmUgcnVubmluZyBzbWFsbCBDUFVzLg0KPiBCdXQgdGhpcyBjYW4gYmUgY2hhbmdlZCBhcyB3 aXNoIGJ5IHRoZSB1c2VyIGFuZCBieSBzeXN0ZW1kLiBUaGV5IHRvbGQgdXMNCj4gdGhleSB0b29r IG9uZSBhcmJpdHJhcnkgdmFsdWUgYnkgZGVmYXVsdCwgYW5kIHdlIGNhbiBjaGFuZ2UgaXQuDQo+ IA0KPiBXZSBjYW4gYXNrIHN5c3RlbWQvbG9naW5kIHRvIGNoYW5nZSBwYXJ0IG9mIHRoZSBiZWhh dmlvciBmb3IgbmV3IGRldmljZXMNCj4gd2hlbiB0aGVyZSBpcyBhIGJ1Zy4gQnV0IHdlIGNhbid0 IGFzayB0aGVtIHRvIGNoYW5nZSB0aGUgd2hvbGUgZGVzaWduDQo+IGJlY2F1c2UgdGhlcmUgaXMg YSByZWdyZXNzaW9uIGluIHRoZSBrZXJuZWwuDQoNClRoYXQgc291bmRzIGdyZWF0IQ0KSWYgc3lz dGVtZC9sb2dpbmQgY2FuIGJlIGNoYW5nZWQsIGNhbiB3ZSBhc2sgc3lzdGVtZC9sb2dpbmQgdG8g Y2hhbmdlIGl0IHRvIGJlIGxvbmdlciBlbm91Z2guDQpGb3IgZXhhbXBsZSwgYWxsb3dpbmcgdXNl cnMgdG8gY29uZmlndXJlIHRoaXMgdG8gIklORklOSVRFIj8NClRoYXQgc29sdmVzIG1hbnkgb3Ro ZXIgcHJvYmxlbXMuDQoNCk5PVEUsIEVWX1NXIGlzIGEgZ29vZCBmZWF0dXJlIHRvIHJlZHVjZSBk dXBsaWNhdGVkIGV2ZW50cywNCmJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiB1c2VycyBvZiBFVl9TVyBu ZWVkIHRvIGJlIHNvIHN0cmljdCB0byB0aGUgdGltaW5ncyBvZiBTV19MSUQsIHJpZ2h0Pw0KDQpJ ZiBpdCBjYW4gYmUgY29uZmlndXJlZCB0byAiSU5GSU5JVEUiLCB3aXRoICJpZ25vcmUiIG1vZGUs DQpzeXN0ZW1kL2xvZ2luZCBzaG91bGQgYWx3YXlzIGJlIGFibGUgdG8gc2VlIGFuICJvcGVuIiBl dmVudCBiZWZvcmUgc2VlaW5nIGEgbmV3IEJJT1MgdHJpZ2dlcmVkICJjbG9zZSIgZXZlbnRzLg0K DQpTbyB3aHkgZG8geW91IHJlZnVzZSB0aGUgcG9zc2liaWxpdGllcyBvZiB1c2luZyAib3Blbi9p Z25vcmUiIGFzIGRlZmF1bHQgbW9kZXM/DQoNCj4gPiAyLiBXaG8gc2hvdWxkIGJlIHJlc3BvbnNp YmxlIGZvciBmaXhpbmcgdGhpcyBpc3N1ZSBhZnRlciByZXZlcnRpbmcgdG8gIm1ldGhvZCIgbW9k ZToNCj4gPiAgICBodHRwczovL2J1Z3ppbGxhLmtlcm5lbC5vcmcvc2hvd19idWcuY2dpP2lkPTEw NjE1MQ0KPiANCj4gbGliaW5wdXQgd2lsbCBjaGFuZ2UgdGhlIHZhbHVlIHRvIG9wZW4gZ2l2ZW4g dGhlIGhldXJpc3RpY3Mgd2UgaGF2ZS4NCg0KWWVzLCBJIHNlZS4NCkJ1dCBJIGFsc28gY2FuIHNl ZSBvbmUgYnJva2VuIGNhc2UgY2Fubm90IGJlIHdvcmtlZCBhcm91bmQgYnkgbGliaW5wdXQgaWYg eW91IGluc2lzdCB0byB1c2UgIm1ldGhvZCIuDQoNCj4gPiAgICBXaGF0J3MgdGhlIHJvb3QgY2F1 c2Ugb2YgdGhpcyBpc3N1ZT8NCj4gDQo+IFBvb3JseSB3cml0dGVuIEVDPw0KPiBJdCBkb2Vzbid0 IG1hdHRlci4gV2Uga25vdyB0aGUgbWFjaGluZSBpcyBidWdneSwgd2UnbGwganVzdCBuZWVkIGEN Cj4gd29ya2Fyb3VuZC4NCg0KSXQgc2VlbXMgeW91IGtub3cgYmV0dGVyIHRoYW4gdGhlIFNBTVNV Tkcgb2ZmaWNpYWwgc3VwcG9ydGVycz8NClRoZSAxMC0yMCBzZWNvbmRzIGxhZyBjYW4gYmUgc2Vl biBldmVuIG9uIFdpbmRvd3M6DQpodHRwOi8vd3d3LnNhbXN1bmcuY29tL3VrL3N1cHBvcnQvbW9k ZWwvTlAtTjIxMC1KUDAyVUsNCg0KU2luY2UgeW91IHNlZW0gdG8gYmUgYWJsZSB0byBzZWUgc29t ZXRoaW5nIEknbSBub3QgYXdhcmUgb2YuDQpMZXQgbWUgYXNrLCB3aGljaCBkbyB5b3UgbWVhbiBi eSB1c2luZyB3b3JkICJwb29ybHkiLCBFQyBkcml2ZXIgb3IgRUMgZmlybXdhcmU/DQpJZiBpdCdz IEVDIGRyaXZlciwgY2FuIHlvdSBmaXggaXQ/DQoNCj4gPiAzLiBIb3cgY2FuIHdlIGdlbmVyYXRl IHRoZSBxdWlyayBmb3IgdGhlIGZvbGxvd2luZyBwb3NzaWJsZSBicmVha2FnZToNCj4gPiAgICBO byBsaWQgbm90aWZpY2F0aW9uIGFuZCBfTElEIHJldHVybiBjYWNoZWQgb3BlbiBhZnRlciBib290 L3Jlc3VtZQ0KPiANCj4gIm1ldGhvZCIgd2lsbCBmZXRjaCBhbmQgcmVwb3J0IHRoZSBjYWNoZWQg X0xJRCB2YWx1ZSBhcyBvcGVuLCBzbyB0aGVyZQ0KPiBpcyBubyBicmVha2FnZS4gVW5sZXNzIHRo ZSBsaWQgaXMgYWN0dWFsbHkgY2xvc2VkIGFuZCB0aGUgRUMgaXMgcGxhaW4NCj4gd3JvbmcsIGJ1 dCB0aGF0IGlzIHNvbWV0aGluZyB3ZSBjYW4gYWxzbyBleHBsYWluIHRvIHVzZXJzIG9yIGZpeCBi eSBhbg0KPiBvdGhlciBtZWFuLiBCdXQgbm90aGluZyBnZW5lcmljIHdpbGwgd29yay4gRm9yIGlu c3RhbmNlLCBvbiB0aGUgU3VyZmFjZQ0KPiAzLCB0aGUgTElEIG5vdGlmaWNhdGlvbiBmb3Igb3Bl biBpc24ndCBmb3J3YXJkZWQsIHNvIEkgd3JvdGUgYSBzcGVjaWZpYw0KPiBkcml2ZXIgdG8gZ2V0 IHRoZSBjb3JyZWN0IGJlaGF2aW9yIGJhc2VkIG9uIGEgY2FyZWZ1bCBhbmFseXNpcyBvZiB0aGUN Cj4gRFNEVC4NCg0KRmlyc3QsIEkgY291bGRuJ3Qgc2VlIGFueXRoaW5nIHJlbGF0ZWQgdG8gRUMg aGVyZSBidXQgeW91IGtlcHQgb24gdGFsa2luZyBFQy4NCkRvIHlvdSBoYXZlIHBlcnNvbmFsIGZl ZWxpbmdzIGFnYWluc3QgRUM/DQoNCkluIGZhY3QsIHRoaXMgaXMganVzdCBhIHRoZW9yZXRpY2Fs IGlzc3VlIHNob3dpbmcgdGhhdCBzb21ldGhpbmcgY2Fubm90IGJlIHdvcmtlZCBhcm91bmQgYnkg bGliaW5wdXQgd2hlbiAibWV0aG9kIiBpcyB0aGUgZGVmYXVsdCBtb2RlLg0KSSBkb24ndCBldmVu IGtub3cgYW55IHBsYXRmb3JtIGFjdGluZyBpbiB0aGlzIHdheS4NCkJ1dCBpdCBpcyBsaWtlbHkg dGhlcmUgYXJlIHN1Y2ggcGxhdGZvcm1zIGFzIHRoZSBkZWZhdWx0ICJtZXRob2QiIG1vZGUgbWF5 IGNhdXNlIHRoZW0gaW52aXNpYmxlIHRvIHVzLg0KDQpUaGUgYnJva2VuIGNhc2VzIHJlbGF0ZWQg dG8gdGhlIHRpbWluZyBhcmU6DQoxLiBJZiBsaWJpbnB1dCB3cml0ZXMgImNsb3NlIiBhZnRlciBi dXR0b24gZHJpdmVyIHNlbmRzIGluaXRpYWwgbm90aWZpY2F0aW9uIHVzaW5nIF9MSUQgcmV0dXJu IHZhbHVlOg0KICAgRm9yIGEgcGxhdGZvcm0gdGhhdCBoYXMgbm8gbGlkIG5vdGlmaWNhdGlvbiBh bmQgX0xJRCByZXR1cm4gY2FjaGVkICJvcGVuIiBhZnRlciBib290L3Jlc3VtZS4NCiAgIElmIHN1 Y2ggYSBzeXN0ZW0gY29ubmVjdHMgdG8gYW4gZXh0ZXJuYWwgbW9uaXRvciwgYW5kIHVzZXJzIGNv bmZpZ3VyZSB0byB1c2UgZXh0ZXJuYWwgZGlzcGxheSwgdGhlbg0KICAgIm9wZW4iIHdpbGwgYXJy aXZlIHVzZXIgc3BhY2UgcHJvZ3JhbXMgZmlyc3QsIHRodXMgaW50ZXJuYWwgbW9uaXRvciB3aWxs IGJlIGxpdCBvbiBhbmQgZXh0ZXJuYWwgb25lIHdpbGwgYmUgbGl0IG9mZi4NCiAgIFdoaWNoIGlz IG5vdCB3aGF0IHVzZXJzIHdhbnQuDQoyLiBJZiBsaWJpbnB1dCB3cml0ZXMgImNsb3NlIiBiZWZv cmUgYnV0dG9uIGRyaXZlciBzZW5kcyBpbml0aWFsIG5vdGlmaWNhdGlvbiB1c2luZyBfTElEIHJl dHVybiB2YWx1ZToNCiAgIEZvciBhIHBsYXRmb3JtIHRoYXQgaGFzIG5vIGxpZCBub3RpZmljYXRp b24gYW5kIF9MSUQgcmV0dXJuIGNhY2hlZCAiY2xvc2UiIGFmdGVyIGJvb3QvcmVzdW1lLg0KICAg SWYgc3VjaCBhIHN5c3RlbSBjb25uZWN0cyB0byBhbiBleHRlcm5hbCBtb25pdG9yLCBhbmQgdXNl cnMgY29uZmlndXJlIHRvIHVzZSBpbnRlcm5hbCBkaXNwbGF5LCB0aGVuDQogICAiY2xvc2UiIHdp bGwgYXJyaXZlIHVzZXJzcGFjZSBwcm9ncmFtcyBmaXJzdCwgdGh1cyBpbnRlcm5hbCBtb25pdG9y IHdpbGwgYmUgbGl0IG9mZiBhbmQgZXh0ZXJuYWwgb25lIHdpbGwgYmUgbGl0IG9uLg0KICAgV2hp Y2ggaXMgbm90IHdoYXQgdXNlcnMgd2FudC4NCiAgIFRoZXJlIGFyZSBldmVuIG1vcmUgY2FzZXMg YnJva2VuIGlmIGxpYmlucHV0IHdyaXRlcyAiY2xvc2UiIGJlZm9yZSBidXR0b24gZHJpdmVyIHNl bmRzIGluaXRpYWwgbm90aWZpY2F0aW9uIHVzaW5nIF9MSUQgcmV0dXJuIHZhbHVlLg0KU28gZWl0 aGVyIDEgb3IgMiB3aWxsIGJlIGJyb2tlbi4NCldoYXQgSSBzdXBwb3NlZCB3YXMgMSB3b3VsZCBi ZSBicm9rZW4gdGh1cyBJIGxpc3RlZCBzdWNoIHRoZW9yZXRpY2FsIHBsYXRmb3JtLg0KDQpDaGVl cnMsDQpMdg0K -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Lv > > Yes, it's called a quirk. And the good practice is to register those > > quirks and make them available to everybody. Being in hwdb in user space > > or in acpi/button in kernel space doesn't matter, we need them. > > I have no objections but concerns related to the combination of "default mode" and "quirk responsibles". > From my point of view, these are my conclusions: > 1. If you want to use libinput to generate quirks, you should use "ignore" > rather than "method" mode as default mode; libinput does not replace the kernel. libinput can help with some heuristics, but that should be the exception, not the default. And heuristics cannot detect some cases, ignore suffers from that problem (see below). > 2. If you want to use button driver to generate quirks, we need "close" mode; > 3. If GDM can change or users are ok use command lines, we can remain to use "open" as the default behavior. > (I'll send technical details in private about these conclusions) > But you seem to always: > 1. Say no to "ignore" which makes 1 impossible; as an outsider, 'ignore' makes me wonder: Why wouldn't you query the state of the hardware if it lets you? That's what we do in userspace with EV_SW. We don't just rely on the notification, we look at the state of it too. sure, some hardware is buggy and we can somehow work around this but that's not a reason to throw everyone else under the bus too. > 2. Say no to "close" which makes 2 impossible; 'close' forces userspace to fix up the kernel in every case rather than for those devices where method doesn't work correctly. That's just effectively deciding to be always the least wrong just to avoid a few outliers. (also, if the kernel is always wrong, what purpose does it serve? :) > 3. Say no to "open" which makes 3 impossible. as mentioned above, some things we cannot detect. we cannot detect a false-open with heuristics, this makes it impossible to fix with heuristics in userspace. for 'close' and 'method' we can take user input as indication that the lid isn't as closed as it pretends to be. That doesn't work the other way round, lack of user input does not imply the lid is closed. > > > We haven't asked user space to change. > > > We are just discussing the correctness of some user space behaviors. > > > > They *are* correct. > > They are following the exported ACPI documentation > > I doubt. In ACPI world, Windows is the only standard. ok, here I need to note something: ACPI doesn't matter to userspace. the kernel has EV_SW/SW_LID, which is *not* ACPI. that promises that a userspace can assume that if SW_LID is 1, then the lid is closed, otherwise it's open. Some leeway can be given because, well, reality, but a userspace behaviour to assume a lid is closed when the lid switch is set to that state should not be up for discussion. > > and the input node documentation. > > Quoting the input doc: > > file Documentation/input/event-codes.rst: > > EV_SW > > ----- > > > > EV_SW events describe stateful binary switches. For example, the SW_LID code is > > used to denote when a laptop lid is closed. > > > > Upon binding to a device or resuming from suspend, a driver must report > > the current switch state. This ensures that the device, kernel, and userspace > > state is in sync. > > > > Upon resume, if the switch state is the same as before suspend, then the input > > subsystem will filter out the duplicate switch state reports. The driver does > > not need to keep the state of the switch at any time. > > ---- > > That's really a convenient feature for driver. > If I'm the driver writers, I would be very appreciated for being able to use such features. > So you see I don't have objections to having this feature. > > I just have concerns related to: > 1. Is it required to have a timeout in systemd, forcing platform to suspend again, just due to event delays? > 2. Is it required to use SW_LID to determine whether an internal display should be lit on? > I don't see any conflicts between the ABI of EV_SW and the 2 questions. the ABI of EV_SW? that's just evdev. It seems you're discussing three, four things simultaneously, ACPI, the button driver, the evdev switch API and userspace behaviour in response to this whole thread. The simple answer is: the last bit doesn't matter - if EV_SW/SW_LID is on, the lid can be assumed to be closed. How you get to this point is your side of the problem :) And I'm willing to accommodate for some issues (see the heuristics benjamin already mentioned) but they should be exception, not the rule. but whether e.g. displays are lit or not has nothing to do with this discussion, it just doesn't matter what userspace does with the information. > > So no, you can't have 'ignore' or 'open' to be the default, because user > > space expects the switch to reflect the current state of the hardware. > > Then what's the benefit of having 'method' to be the default, > Given it is still not able to reliably deliver the current state of hardware? isn't this just a case of: method is less wrong than ignore? 100% reliability is not possible given the hardware available on the market, but it seems that 'method' is the least wrong of them, followed by ignore, trailed by open and close. > Actually both 'ignore/open/method' modes are trying to be compliant to EV_SW. "compliant to EV_SW" just means "SW_LID state reflects state of the hardware", right? > Among them, "ignore" did the best IMO. how did ignore do better than method? what devices give you an incorrect state but send you a correct notification later? And even then it would only matter for 50% of the cases anyway, because a false state of open first followed by a close notification later wouldn't matter. > And cases broken in "ignore" mode but not broken in "method" mode are all issues: > - Platform doesn't send notification after boot/resume. > IMO, we should also collect them and indicate them to desktop managers. > > So in the end, we just have differences related to picking which default mode. > > > > > You can not also change the semantic of an input switch. An input > > > > switch, as per the input subsystem is supposed to forward an actual > > > > state of the underlying hardware. Any fake information is bad and has to > > > > be avoided. > > > Since fake events are harmful, why do we fake an event after boot/resume? > > > button.lid_init_state=method seems can fake such an event. > > We don't fake an event, we are syncing the input switch state with the > > hardware. > > Faking an event is when you send "switch is open" while you know there > > is a possibility it's actually closed. > > No we are faking events in this mode. > _LID can return cached state, and: > 1. it might be "close" while LID is "open" after suspend. > 2. it might be "open" while LID is "close" after suspend. > In this case, it explains the side effect of having type 1 fake event: > https://bugzilla.kernel.org/show_bug.cgi?id=106151 > If we don't evaluate _LID and send such a "close", the platform can > correctly send "open" just with a delay. side-note: _LID and LID makes for confusing reading. _LID is ACPI and LID is SW_LID? if acpi/the hw gives you an incorrect cached state, you'll need to quirk *that* hardware, because it's more broken than others. > > > > I already gave you 2 solutions to fix the 7 machines you see that are > > > > problematic, and you just seem to ignore them: > > > > - revert to the v4.10 behavior and let libinput fix that for you > > > > > > I already chose this. > > > But I just raised a concern that button.lid_init_state=method could bring troubles to libinput > > quirks. > > > > No. We can do whatever we want in libinput. And we can fix hardware when > > it appears. We don't need to have the correct solution for everybody, > > ever. libinput is a library and it can be updated, and we can ask users > > to upgrade. We can even break the API by bumping the soname. We have > > much more liberty that the kernel has, so the libinput implementation > > shouldn't be a concern. > > It seems you don't know all the details I was looking at. > It's about a timing problem, with button.lid_init_state=method and libinput quirk, we actually have 2 quirks. > And libinput write can appear before/after the faked init notification triggered by "method" mode. > Causing some cases not workaroundable. > See below for details. see below for answers, but basically: if libinput writes the correct state before the notification arrives, *nothing* happens in userspace. The kernel filters duplicate events, so even if libinput sets the state before the kernel driver does, userspace won't receive an event. > > > No, I currently cannot persuade myself to revert to "method" mode. > > > But that doesn't mean I don't want to or I want to. > > > You just didn't prove that by answering my questions in PATCH 1/2 and in this email. > > > Especially: > > > 1. After reverting to "method" mode, can libinput work all cases around? > > If it doesn't, we'll fix it. So yes, it will eventually. > > That's great. > > > > Are there any timing issues that can prevent libinput from working some sucks around. > > > Considering this case, it's likely such problems can happen. > > > https://bugzilla.kernel.org/show_bug.cgi?id=106151 > > > > logind has a delay between the time it starts and the time it starts > > polling the lid switch state. The default value is a little bit too > > short on Fedora considering the faulty devices are running small CPUs. > > But this can be changed as wish by the user and by systemd. They told us > > they took one arbitrary value by default, and we can change it. > > > > We can ask systemd/logind to change part of the behavior for new devices > > when there is a bug. But we can't ask them to change the whole design > > because there is a regression in the kernel. > > That sounds great! > If systemd/logind can be changed, can we ask systemd/logind to change it to be longer enough. > For example, allowing users to configure this to "INFINITE"? > That solves many other problems. > > NOTE, EV_SW is a good feature to reduce duplicated events, > but that doesn't mean users of EV_SW need to be so strict to the timings of SW_LID, right? > > If it can be configured to "INFINITE", with "ignore" mode, > systemd/logind should always be able to see an "open" event before seeing a new BIOS triggered "close" events. > > So why do you refuse the possibilities of using "open/ignore" as default modes? > > > > 2. Who should be responsible for fixing this issue after reverting to "method" mode: > > > https://bugzilla.kernel.org/show_bug.cgi?id=106151 > > > > libinput will change the value to open given the heuristics we have. > > Yes, I see. > But I also can see one broken case cannot be worked around by libinput if you insist to use "method". > > > > What's the root cause of this issue? > > > > Poorly written EC? > > It doesn't matter. We know the machine is buggy, we'll just need a > > workaround. > > It seems you know better than the SAMSUNG official supporters? > The 10-20 seconds lag can be seen even on Windows: > http://www.samsung.com/uk/support/model/NP-N210-JP02UK > > Since you seem to be able to see something I'm not aware of. > Let me ask, which do you mean by using word "poorly", EC driver or EC firmware? > If it's EC driver, can you fix it? > > > > 3. How can we generate the quirk for the following possible breakage: > > > No lid notification and _LID return cached open after boot/resume > > > > "method" will fetch and report the cached _LID value as open, so there > > is no breakage. Unless the lid is actually closed and the EC is plain > > wrong, but that is something we can also explain to users or fix by an > > other mean. But nothing generic will work. For instance, on the Surface > > 3, the LID notification for open isn't forwarded, so I wrote a specific > > driver to get the correct behavior based on a careful analysis of the > > DSDT. > > First, I couldn't see anything related to EC here but you kept on talking EC. > Do you have personal feelings against EC? let's not go down that type of discussion please... > In fact, this is just a theoretical issue showing that something cannot be > worked around by libinput when "method" is the default mode. > I don't even know any platform acting in this way. > But it is likely there are such platforms as the default "method" mode may > cause them invisible to us. note: it may be likely, but it's a *definitive* that existing platforms break with the current 'open'... > The broken cases related to the timing are: > 1. If libinput writes "close" after button driver sends initial notification using _LID return value: This is a theoretical case only. libinput does not write close, ever. because there is no heuristics we can use that can guarantee that the lid is closed (well, short of enabling the camera and checking if it looks really dark, but let's not do that ;) > For a platform that has no lid notification and _LID return cached "open" after boot/resume. > If such a system connects to an external monitor, and users configure to use external display, then > "open" will arrive user space programs first, thus internal monitor will be lit on and external one will be lit off. > Which is not what users want. > 2. If libinput writes "close" before button driver sends initial notification using _LID return value: see 1, libinput does not write 'close'. also, just in case that's not obvious yet: libinput behaviour is a) internal to libinput and b) tailored to the hardware. The current behaviour works for the devices we've needed to fix. We can change that at any time and we can add other behaviours at any time. So even if some theoretical platforms appear that do the wrong thing - we can deal with it then and figure out. note also, that the only reason libinput even writes the switch event to the event node is because we are nice to others. We have that information (user is typing, therefore lid is not closed) so we share it with anyone else by changing the device's state. This way other processes can pick it up, without needing the same heuristics. Cheers, Peter > For a platform that has no lid notification and _LID return cached "close" after boot/resume. > If such a system connects to an external monitor, and users configure to use internal display, then > "close" will arrive userspace programs first, thus internal monitor will be lit off and external one will be lit on. > Which is not what users want. > There are even more cases broken if libinput writes "close" before button driver sends initial notification using _LID return value. > So either 1 or 2 will be broken. > What I supposed was 1 would be broken thus I listed such theoretical platform. > > Cheers, > Lv -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Lv, [thank you Peter for jumping in the thread] Just a few precisions regarding questions you asked: On May 17 2017 or thereabouts, Zheng, Lv wrote: [stripped] > > [User space tools] *are* correct. > > They are following the exported ACPI documentation > > I doubt. In ACPI world, Windows is the only standard. I was talking here about the i915 driver that uses the Linux ACPI documentation in regard to the call of acpi_lid_open(). User space tool shouldn't rely on the _LID call through the sysfs if acpi/button.c actaully forwards the ACPI call, because it is clear now that it is not reliable in all situations. > > > and the input node documentation. > > Quoting the input doc: > > file Documentation/input/event-codes.rst: > > EV_SW > > ----- > > > > EV_SW events describe stateful binary switches. For example, the SW_LID code is > > used to denote when a laptop lid is closed. > > > > Upon binding to a device or resuming from suspend, a driver must report > > the current switch state. This ensures that the device, kernel, and userspace > > state is in sync. > > > > Upon resume, if the switch state is the same as before suspend, then the input > > subsystem will filter out the duplicate switch state reports. The driver does > > not need to keep the state of the switch at any time. > > ---- > > That's really a convenient feature for driver. > If I'm the driver writers, I would be very appreciated for being able to use such features. > So you see I don't have objections to having this feature. It's not a feature on how the system could be improved, it's the definition of an input node that relay an EV_SW element. acpi/button.c exports a LID_SW, so it has to conform to the definition. That is not something we should be discussing. > > I just have concerns related to: > 1. Is it required to have a timeout in systemd, forcing platform to suspend again, just due to event delays? > 2. Is it required to use SW_LID to determine whether an internal display should be lit on? > I don't see any conflicts between the ABI of EV_SW and the 2 questions. As Peter mentioned, the users of the switch are doing what they want. But if you don't have the LID_SW input node, you can not know the state of the laptop (opened or closed). So yes, it's there for a reason. [stripped] > > No. We can do whatever we want in libinput. And we can fix hardware when > > it appears. We don't need to have the correct solution for everybody, > > ever. libinput is a library and it can be updated, and we can ask users > > to upgrade. We can even break the API by bumping the soname. We have > > much more liberty that the kernel has, so the libinput implementation > > shouldn't be a concern. > > It seems you don't know all the details I was looking at. > It's about a timing problem, with button.lid_init_state=method and libinput quirk, we actually have 2 quirks. > And libinput write can appear before/after the faked init notification triggered by "method" mode. See Peter's answer (nothing will happen in user-space), but I just wanted to raised the fact that the "method" parameter doesn't trigger "faked init notifications". The "method" parameter only syncs the state with the hardware. And given this happens in the .resume() callback, it means that users will have to wait for the resume to finish before taking any action. So it's on their side that there is a problem if they are reading the state before the kernel even had the chance to update it. [stripped] > That sounds great! > If systemd/logind can be changed, can we ask systemd/logind to change it to be longer enough. > For example, allowing users to configure this to "INFINITE"? I think they have a good reason but I never fully understood why they have to poll on the state. > That solves many other problems. > > NOTE, EV_SW is a good feature to reduce duplicated events, > but that doesn't mean users of EV_SW need to be so strict to the timings of SW_LID, right? When an input event happens over evdev, it's expected that the user treats it immediately. In the LID_SW case we can somewhat tell user space that they need to be extra careful, but they can argue that we should comply to the definition of an input switch, or not exporting it at all. [stripped] > > > > What's the root cause of this issue? > > > > Poorly written EC? > > It doesn't matter. We know the machine is buggy, we'll just need a > > workaround. > > It seems you know better than the SAMSUNG official supporters? I wouldn't pretend to know more than Samsung engineers. All I see is that there is an issue in the notification and/or the acpi _LID call, so all I can say is that there is a bug in the firmware of the embedded controller in charge of answering acpi calls. > The 10-20 seconds lag can be seen even on Windows: > http://www.samsung.com/uk/support/model/NP-N210-JP02UK > > Since you seem to be able to see something I'm not aware of. > Let me ask, which do you mean by using word "poorly", EC driver or EC firmware? 'Driver' implies in the kernel, and I never intended that there was such a bug. If there is, then yes, I'd expect the people in charge of it to fix it. But given the bug also happens in Windows, it's more likely that it's a firmware issue, and it's the responsibility of Samsung to fix it. I thought using EC was more precise that when talking about 'ACPI' because ACPI can also be the project to support it under Linux, not the FW itself. > If it's EC driver, can you fix it? I can't say I can fix anything. I don't have the machine and don't have much time to dedicate to it. So no I guess. > > > > 3. How can we generate the quirk for the following possible breakage: > > > No lid notification and _LID return cached open after boot/resume > > > > "method" will fetch and report the cached _LID value as open, so there > > is no breakage. Unless the lid is actually closed and the EC is plain > > wrong, but that is something we can also explain to users or fix by an > > other mean. But nothing generic will work. For instance, on the Surface > > 3, the LID notification for open isn't forwarded, so I wrote a specific > > driver to get the correct behavior based on a careful analysis of the > > DSDT. > > First, I couldn't see anything related to EC here but you kept on talking EC. > Do you have personal feelings against EC? For me EC == Embedded Controller == Firmware written in it that we both not control (unless Intel writes part of it, which I am not aware of). Sorry if EC means something else for you. Cheers, Benjamin > > In fact, this is just a theoretical issue showing that something cannot be worked around by libinput when "method" is the default mode. > I don't even know any platform acting in this way. > But it is likely there are such platforms as the default "method" mode may cause them invisible to us. > > The broken cases related to the timing are: > 1. If libinput writes "close" after button driver sends initial notification using _LID return value: > For a platform that has no lid notification and _LID return cached "open" after boot/resume. > If such a system connects to an external monitor, and users configure to use external display, then > "open" will arrive user space programs first, thus internal monitor will be lit on and external one will be lit off. > Which is not what users want. > 2. If libinput writes "close" before button driver sends initial notification using _LID return value: > For a platform that has no lid notification and _LID return cached "close" after boot/resume. > If such a system connects to an external monitor, and users configure to use internal display, then > "close" will arrive userspace programs first, thus internal monitor will be lit off and external one will be lit on. > Which is not what users want. > There are even more cases broken if libinput writes "close" before button driver sends initial notification using _LID return value. > So either 1 or 2 will be broken. > What I supposed was 1 would be broken thus I listed such theoretical platform. > > Cheers, > Lv -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Rafael, On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > >> >> Benjamin, my understanding is that this is the case, is it correct? > >> > > >> > That is correct. This patch I reverted introduces regression for professional > >> > laptops that expect the LID switch to be reported accurately. > >> > >> And from a user's perspective, what does not work any more? > > > > If you boot or resume your laptop with the lid closed on a docking > > station while using an external monitor connected to it, both internal > > and external displays will light on, while only the external should. > > > > There is a design choice in gdm to only provide the greater on the > > internal display when lit on, so users only see a gray area on the > > external monitor. Also, the cursor will not show up as it's by default > > on the internal display too. > > > > To "fix" that, users have to open the laptop once and close it once > > again to sync the state of the switch with the hardware state. > > OK > > Yeah, that sucks. > > So without the Lv's patch the behavior (on the systems in question) is > as expected, right? Would you agree to take both these reverts without Lv's ACK? We already tried to explain for 2 weeks that they are valuable, but it seems we can't make change his mind. I have more that 26 emails in my INBOX (not counting my replies) and I would really like switching to more valuable work than explaining again and again that when a regression is introduced, it needs to be fixed (or reverted in that case). Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, May 24, 2017 at 10:08 AM, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote: > Hi Rafael, > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: >> >> >> Benjamin, my understanding is that this is the case, is it correct? >> >> > >> >> > That is correct. This patch I reverted introduces regression for professional >> >> > laptops that expect the LID switch to be reported accurately. >> >> >> >> And from a user's perspective, what does not work any more? >> > >> > If you boot or resume your laptop with the lid closed on a docking >> > station while using an external monitor connected to it, both internal >> > and external displays will light on, while only the external should. >> > >> > There is a design choice in gdm to only provide the greater on the >> > internal display when lit on, so users only see a gray area on the >> > external monitor. Also, the cursor will not show up as it's by default >> > on the internal display too. >> > >> > To "fix" that, users have to open the laptop once and close it once >> > again to sync the state of the switch with the hardware state. >> >> OK >> >> Yeah, that sucks. >> >> So without the Lv's patch the behavior (on the systems in question) is >> as expected, right? > > Would you agree to take both these reverts without Lv's ACK? We already > tried to explain for 2 weeks that they are valuable, but it seems we > can't make change his mind. One of the reverts actually is already in (as a patch from Lv) and I'll most probably push the other one for -rc4 next week. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, > >> >> >> Benjamin, my understanding is that this is the case, is it correct? > >> >> > > >> >> > That is correct. This patch I reverted introduces regression for professional > >> >> > laptops that expect the LID switch to be reported accurately. > >> >> > >> >> And from a user's perspective, what does not work any more? > >> > > >> > If you boot or resume your laptop with the lid closed on a docking > >> > station while using an external monitor connected to it, both internal > >> > and external displays will light on, while only the external should. > >> > > >> > There is a design choice in gdm to only provide the greater on the > >> > internal display when lit on, so users only see a gray area on the > >> > external monitor. Also, the cursor will not show up as it's by default > >> > on the internal display too. > >> > > >> > To "fix" that, users have to open the laptop once and close it once > >> > again to sync the state of the switch with the hardware state. > >> > >> OK > >> > >> Yeah, that sucks. > >> > >> So without the Lv's patch the behavior (on the systems in question) is > >> as expected, right? > > > > Would you agree to take both these reverts without Lv's ACK? We already > > tried to explain for 2 weeks that they are valuable, but it seems we > > can't make change his mind. It's not that difficult to get an agreement. We just didn't communicate well. > One of the reverts actually is already in (as a patch from Lv) and > I'll most probably push the other one for -rc4 next week. If we really want to go back to "method" mode. We need one more patch and it is not in Benjamin's series. There are 3 known broken cases, 2 of them are related to orders. The last 1 is not order related: 1. Surface Pro 3: open arrives very early to update cached value, not notification 2. Samsung N210+: open arrives very late to update cached value, not notification 3. Surface Pro 1: no open event, _LID keeps on returning close The order problem is (considering method mode): _Qxx <- Invoked due to EC events Update _LID return value Notify(LID, close) input_report(SW_LID 1) -> captured by user space and system starts to suspend acpi_button_suspend acpi_ec_suspend acpi_ec_disable_event acpi_button_resume if (method) input_report(SW_LID, _LID return value, would be 1 for cached value) acpi_ec_resume acpi_ec_enable_event _Qxx <- Invoked due to EC events, for broken case 3, no such event Update _LID return value Notify(LID, open) <- for broken case 1, 2, 3, no such notification, thus open cannot be delivered to user space. input_report(SW_LID, 0) The order of acpi_button_resume()/acpi_ec_resume() is determined by the enumeration order. So it could vary on different platforms. Considering case 1, for surface pro 3, where acpi_button_resume() is invoked before acpi_ec_resume(). Button driver will send false "close" to user space, and the updated "open" state won't be delivered to user space. Staying in method mode, we can only suspend the system once, follow-up "close" events won't arrive to user space. Even we can add many workarounds to make sure acpi_ec_resume() is executed before acpi_button_resume() on such platforms. We still cannot fix case 2 and case 3. So finally this order still cannot be ensured, and the solution is still not stable. I would imagine the order problem is the key reason why MS stops sending "open" on these platforms. Then given this order issue is not fixable, we need to fix broken case 1 by adding "complement event" in "method" mode. Why don't we do this first before reverting to "method" mode? And for broken stuffs like case 2/case 3, IMO, they can only be solved using "ignore" mode, and changes in user space. If we don't use this solution, we still need libinput quirks to handle them (may possibly encounter some new unfixable problems). If you want to stay in "method" mode, will you be responsible for responding end users on kernel Bugzilla using libinput quirks? We have a Power-Lid category now, we can have you guys as default assignee. Cheers, Lv
On May 25 2017, Benjamin Tissoires wrote: > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > > >> >> Benjamin, my understanding is that this is the case, is it correct? > > >> > > > >> > That is correct. This patch I reverted introduces regression for professional > > >> > laptops that expect the LID switch to be reported accurately. > > >> > > >> And from a user's perspective, what does not work any more? > > > > > > If you boot or resume your laptop with the lid closed on a docking > > > station while using an external monitor connected to it, both internal > > > and external displays will light on, while only the external should. > > > > > > There is a design choice in gdm to only provide the greater on the > > > internal display when lit on, so users only see a gray area on the > > > external monitor. Also, the cursor will not show up as it's by default > > > on the internal display too. > > > > > > To "fix" that, users have to open the laptop once and close it once > > > again to sync the state of the switch with the hardware state. > > > > OK > > > > Yeah, that sucks. > > > > So without the Lv's patch the behavior (on the systems in question) is > > as expected, right? > > Would you agree to take both these reverts without Lv's ACK? We already > tried to explain for 2 weeks that they are valuable, but it seems we > can't make change his mind. > > I have more that 26 emails in my INBOX (not counting my replies) and I > would really like switching to more valuable work than explaining again > and again that when a regression is introduced, it needs to be fixed (or > reverted in that case). Yes please. This should have stopped right after "regression on basically every decent laptop out there" and we should be discussing how to fix the devices that actually need quirks because they're broken. Instead it turned into a discussion on why we should stick with the regression and convince all of userspace to change and implement broken heuristics. I've used up my time budget for that. Cheers, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, May 26, 2017 05:39:53 PM Peter Hutterer wrote: > On May 25 2017, Benjamin Tissoires wrote: > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote: > > > > >> >> Benjamin, my understanding is that this is the case, is it correct? > > > >> > > > > >> > That is correct. This patch I reverted introduces regression for professional > > > >> > laptops that expect the LID switch to be reported accurately. > > > >> > > > >> And from a user's perspective, what does not work any more? > > > > > > > > If you boot or resume your laptop with the lid closed on a docking > > > > station while using an external monitor connected to it, both internal > > > > and external displays will light on, while only the external should. > > > > > > > > There is a design choice in gdm to only provide the greater on the > > > > internal display when lit on, so users only see a gray area on the > > > > external monitor. Also, the cursor will not show up as it's by default > > > > on the internal display too. > > > > > > > > To "fix" that, users have to open the laptop once and close it once > > > > again to sync the state of the switch with the hardware state. > > > > > > OK > > > > > > Yeah, that sucks. > > > > > > So without the Lv's patch the behavior (on the systems in question) is > > > as expected, right? > > > > Would you agree to take both these reverts without Lv's ACK? We already > > tried to explain for 2 weeks that they are valuable, but it seems we > > can't make change his mind. > > > > I have more that 26 emails in my INBOX (not counting my replies) and I > > would really like switching to more valuable work than explaining again > > and again that when a regression is introduced, it needs to be fixed (or > > reverted in that case). > > Yes please. This should have stopped right after "regression on basically > every decent laptop out there" and we should be discussing how to fix the > devices that actually need quirks because they're broken. Instead it > turned into a discussion on why we should stick with the regression and > convince all of userspace to change and implement broken heuristics. I've > used up my time budget for that. Appreciated. Also please note that it actually might help to make the decision. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c index 6d5a8c1..e19f530 100644 --- a/drivers/acpi/button.c +++ b/drivers/acpi/button.c @@ -113,7 +113,7 @@ struct acpi_button { static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier); static struct acpi_device *lid_device; -static u8 lid_init_state = ACPI_BUTTON_LID_INIT_OPEN; +static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD; static unsigned long lid_report_interval __read_mostly = 500; module_param(lid_report_interval, ulong, 0644);
This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025. Even if the method implementation can be buggy on some platform, the "open" choice is worse. It breaks docking stations basically and there is no way to have a user-space hwdb to fix that. On the contrary, it's rather easy in user-space to have a hwdb with the problematic platforms. Then, libinput (1.7.0+) can fix the state of the LID switch for us: you need to set the udev property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'. When libinput detects internal keyboard events, it will overwrite the state of the switch to open, making it reliable again. Given that logind only checks the LID switch value after a timeout, we can assume the user will use the internal keyboard before this timeout expires. For example, such a hwdb entry is: libinput:name:*Lid Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:* LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open Link: https://bugzilla.gnome.org/show_bug.cgi?id=782380 Cc: stable@vger.kernel.org Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> --- drivers/acpi/button.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)