From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zheng, Lv" Subject: RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI Date: Thu, 22 Jun 2017 03:16:09 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E886CED2DAB@SHSMSX101.ccr.corp.intel.com> References: <20170601184632.2980-1-benjamin.tissoires@redhat.com> <20170607074848.GE27006@gardel-login> <20170613100617.GD29589@mail.corp.redhat.com> <1AE640813FDE7649BE1B193DEA596E886CED0386@SHSMSX101.ccr.corp.intel.com> <20170615064715.GA6195@jelly> <1AE640813FDE7649BE1B193DEA596E886CED047B@SHSMSX101.ccr.corp.intel.com> <20170615075755.GA10001@jelly> <1AE640813FDE7649BE1B193DEA596E886CED0A03@SHSMSX101.ccr.corp.intel.com> <20170616072322.GL5085@mail.corp.redhat.com> <1AE640813FDE7649BE1B193DEA596E886CED0AC1@SHSMSX101.ccr.corp.intel.com> <20170616080950.GM5085@mail.corp.redhat.com> <1AE640813FDE7649BE1B193DEA596E886CED0C5E@SHSMSX101.ccr.corp.intel.com> <33C872C7-EFB2-4CA0-8CAD-8B6E8916180C@hadess.net> <1AE640813FDE7649BE1B193DEA596E886CED1419@SHSMSX101.ccr.corp.intel.com> <1497910127.2559.1.camel@hadess.net> <1AE640813FDE7649BE1B193DEA596E886CED1C41@SHSMSX101.ccr.corp.intel.com> <1498040588.2559.30.camel@hadess.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga11.intel.com ([192.55.52.93]:34787 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752507AbdFVDQQ (ORCPT ); Wed, 21 Jun 2017 23:16:16 -0400 In-Reply-To: <1498040588.2559.30.camel@hadess.net> Content-Language: en-US Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Bastien Nocera Cc: Benjamin Tissoires , Peter Hutterer , Lennart Poettering , "Wysocki, Rafael J" , "Rafael J . Wysocki" , "Brown, Len" , Lv Zheng , "linux-acpi@vger.kernel.org" , "systemd-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "linux-input@vger.kernel.org" SGksDQoNCj4gRnJvbTogQmFzdGllbiBOb2NlcmEgW21haWx0bzpoYWRlc3NAaGFkZXNzLm5ldF0N Cj4gU3ViamVjdDogUmU6IFtzeXN0ZW1kLWRldmVsXSBbV0lQIFBBVENIIDAvNF0gUmV3b3JrIHRo ZSB1bnJlbGlhYmxlIExJRCBzd2l0Y2ggZXhwb3J0ZWQgYnkgQUNQSQ0KPiANCj4gT24gVHVlLCAy MDE3LTA2LTIwIGF0IDAyOjQ1ICswMDAwLCBaaGVuZywgTHYgd3JvdGU6DQo+ID4gSGksDQo+ID4N Cj4gPiA+IEZyb206IEJhc3RpZW4gTm9jZXJhIFttYWlsdG86aGFkZXNzQGhhZGVzcy5uZXRdDQo+ ID4gPiBTdWJqZWN0OiBSZTogW3N5c3RlbWQtZGV2ZWxdIFtXSVAgUEFUQ0ggMC80XSBSZXdvcmsg dGhlIHVucmVsaWFibGUNCj4gPiA+IExJRCBzd2l0Y2ggZXhwb3J0ZWQgYnkgQUNQSQ0KPiA+ID4N Cj4gPiA+IE9uIE1vbiwgMjAxNy0wNi0xOSBhdCAwMTo0MyArMDAwMCwgWmhlbmcsIEx2IHdyb3Rl Og0KPiA+ID4gPiA8c25pcD4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IElmIHlvdSBpbXBsZW1lbnQg aXQgaW4gc3VjaCBhIHdheSB0aGF0IEdOT01FIHNldHRpbmdzIGRhZW1vbg0KPiA+ID4gPiA+IGJl aGF2ZXMgd2VpcmRseSwgeW91J2xsIGdldCBteSByZXZlcnQNCj4gPiA+ID4gPiByZXF1ZXN0IGlu IHRoZSBtYWlsLiBEby4gTm90LiBFdmVyLiBMaWUuDQo+ID4gPiA+DQo+ID4gPiA+IEZpcnN0LCBJ IGRvbid0IGtub3cgd2hhdCBzaG91bGQgYmUgcmV2ZXJ0ZWQuLi4NCj4gPiA+ID4gSSBoYXZlIDIg c29sdXRpb25zIGhlcmUgZm9yIHJldmlldywgYW5kIEJlbmphbWluIGhhcyAxLg0KPiA+ID4gPiBB bmQgbm9uZSBvZiB0aGVtIGhhcyBiZWVuIHVwc3RyZWFtZWQuDQo+ID4gPiA+IFdlIGFyZSBqdXN0 IGRpc2N1c3NpbmcuDQo+ID4gPg0KPiA+ID4gVGhlIGRpc2N1c3Npb24gaXMgZ2V0dGluZyB0aXJp bmcgcXVpdGUgZnJhbmtseS4gV2UndmUgYmVlbiBvdmVyDQo+ID4gPiB0aGlzDQo+ID4gPiBmb3Ig bmVhcmx5IGEgeWVhciBub3csIGFuZCB3aXRoIG5vIGVuZCBpbiBzaWdodC4NCj4gPg0KPiA+IFdl IGhhdmUgY29uY2VybnMgdG8gaW50cm9kdWNlIHRvbyBjb21wbGljYXRlZCBsb2dpY3MgdG8gc3Vj aCBhDQo+ID4gc2ltcGxlIGJ1dHRvbiBkcml2ZXIgZXNwZWNpYWxseSB0aGUgbG9naWNzIGFyZSBy ZWxhdGVkIHRvIHBsYXRmb3JtDQo+ID4gZmlybXdhcmUsIGlucHV0IEFCSSBhbmQgdXNlciBzcGFj ZSBiZWhhdmlvcnMuDQo+ID4NCj4gPiBJIHVuZGVyc3RhbmQgdGhlIHNpdHVhdGlvbi4NCj4gPiBB bnl3YXkgdGhpcyBzaG91bGRuJ3QgYmUgYSBiaWcgZGVhbC4NCj4gPiBMZXQncyBwcmVwYXJlIGEg c21hcnRlciBzZXJpZXMgdG8gY29sbGVjdCBhbGwgZml4ZXMgYW5kIHNvbHV0aW9ucw0KPiA+IHdp dGggcnVudGltZSBjb25maWd1cmFibGVzIGFuZCBnZXQgdGhhdCB0byB0aGUgZW5kIHVzZXJzLg0K PiA+IFNvIHRoYXQgd2UgY2FuIGZpZ3VyZSBvdXQgd2hpY2ggaXMgdGhlIHNpbXBsZXN0IHNvbHV0 aW9uLg0KPiA+DQo+ID4gQnV0IGJlZm9yZSB0aGF0LCBsZXQgbWUgYXNrIHNldmVyYWwgcXVlc3Rp b25zIGFib3V0IGdub21lLXNldHRpbmctDQo+ID4gZGVhbW9uLg0KPiA+DQo+ID4gPg0KPiA+ID4g PiBIb3dldmVyIHdlIG5lZWQgdG8gZ2V0IDEgb2YgdGhlbSB1cHN0cmVhbWVkIGluIG5leHQgY3lj bGUuDQo+ID4gPiA+DQo+ID4gPiA+IEkgdGhpbmsgdXNlcnMgd29uJ3Qgc3RhcnR1cCBnbm9tZS1z ZXR0aW5nLWRhZW1vbiByaWdodCBhZnRlcg0KPiA+ID4gPiByZXN1bWUuDQo+ID4gPiA+IEl0IHNo b3VsZCBoYXZlIGFscmVhZHkgYmVlbiBzdGFydGVkLg0KPiA+ID4gPg0KPiA+ID4gPiBUaGVyZSBp cyBvbmx5IDEgcGxhdGZvcm0gbWF5IHNlZSBkZWxheWVkIHN0YXRlIHVwZGF0ZSBhZnRlcg0KPiA+ ID4gPiByZXN1bWUuDQo+ID4gPiA+IExldCdzIHNlZSBpZiB0aGVyZSBpcyBhIHByYWN0aWNhbCBp c3N1ZS4NCj4gPiA+ID4gMS4gQmVmb3JlIHN1c3BlbmQsIHRoZSAibGlkIHN0YXRlIiBpcyAiY2xv c2UiLCBhbmQNCj4gPiA+ID4gMi4gQWZ0ZXIgcmVzdW1lLCB0aGUgc3RhdGUgbWlnaHQgcmVtYWlu ICJjbG9zZSIgZm9yIGEgd2hpbGUNCj4gPiA+ID4gICAgU2luY2UgbGliaW5wdXQgd29uJ3QgZGVs aXZlciBjbG9zZSB0byB1c2Vyc3BhY2UsDQo+ID4gPiA+ICAgIGFuZCBnbm9tZS1zZXR0aW5nLWRh ZW1vbiBsaXN0ZW5zIHRvIGtleSBzd2l0Y2hlcywgdGhlcmUgaXMgbm8NCj4gPiA+ID4gd3Jvbmcg YmVoYXZpb3IuDQo+ID4gPg0KPiA+ID4gSXQgZG9lc24ndC4gSXQgbGlzdGVucyB0byBVUG93ZXIs IHdoaWNoIHRlbGxzIHVzZXItc3BhY2Ugd2hldGhlcg0KPiA+ID4gdGhlcmUNCj4gPiA+IGlzIGEg bGlkIHN3aXRjaCwgYW5kIHdoZXRoZXIgaXQncyBvcGVuZWQgb3IgY2xvc2VkLg0KPiA+DQo+ID4g VGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uDQo+ID4gSG93ZXZlciBJIGRvbid0IHNlZSBkaWZm ZXJlbmNlcyBoZXJlLg0KPiA+DQo+ID4gPg0KPiA+ID4gPiAzLiBUaGVuIGFmdGVyIHNldmVyYWwg c2Vjb25kcywgIm9wZW4iIGFycml2ZXMuDQo+ID4gPiA+ICAgIGdub21lLXNldHRpbmctZGFlbW9u IHJlLWFycmFuZ2UgbW9uaXRvcnMgYW5kIHNjcmVlbiBsYXlvdXRzIGluDQo+ID4gPiA+IHJlc3Bv bnNlIHRvIHRoZSBuZXcgZXZlbnQuDQo+ID4gPg0KPiA+ID4gSnVzdCBob3cgaXMgYW55b25lIHN1 cHBvc2VkIHRvIGtub3cgdGhhdCB0aGVyZSBpcyBhbiBldmVudCBjb21pbmc/DQo+ID4NCj4gPiBX aWxsIFVQb3dlciBkZWxpdmVyIEVWX1NXIGtleSBldmVudHMgdG8gZ25vbWUtc2V0dGluZy1kYWVt b24/DQo+ID4NCj4gPiA+DQo+ID4gPiA+IFNvIHRoZXJlIGlzIG5vIHByb2JsZW0uIElNTywgdGhl cmUgaXMgbm8gbmVlZCB0byBpbXByb3ZlIGZvcg0KPiA+ID4gPiBwb3N0LQ0KPiA+ID4gPiByZXN1 bWUgY2FzZS4NCj4gPiA+ID4NCj4gPiA+ID4gVXNlcnMgd2lsbCBqdXN0IHN0YXJ0dXAgZ25vbWUt c2V0dGluZy1kYWVtb24gb25jZSBhZnRlciBib290Lg0KPiA+ID4gPiBBbmQgaXQncyBsaWtlbHkg dGhhdCB3aGVuIGl0IGlzIHN0YXJ0ZWQsIHRoZSBzdGF0ZSBpcyBjb3JyZWN0Lg0KPiA+ID4NCj4g PiA+IFlvdSBjYW5ub3QgcmVseSBvbiB3aGVuIGdub21lLXNldHRpbmdzLWRhZW1vbiB3aWxsIGJl IHN0YXJ0ZWQgdG8NCj4gPiA+IG1ha2UNCj4gPiA+ICphbnkqIGRlY2lzaW9uLiBDZXJ0YWlubHkg bm90IGRlY2lzaW9ucyBvbiBob3cgdGhlIGtlcm5lbCBzaG91bGQNCj4gPiA+IGJlaGF2ZS4NCj4g Pg0KPiA+IE15IGJhZCB3b3JkaW5nLCBJIGp1c3QgbWVhbnQ6DQo+ID4gV2hlbiBnbm9tZS1zZXR0 aW5ncy1kYWVtb24gaXMgc3RhcnRlZCBpcyBub3QgcmVsYXRlZCB0byB3aGF0IHdlIGFyZQ0KPiA+ IGRpc2N1c3NpbmcuDQo+ID4NCj4gPiBEbyB5b3Ugd2FudCB0byBmaXggcmVncmVzc2lvbnM/DQo+ ID4gT3IgeW91IHdhbnQgdG8gZml4IG5ldyBpc3N1ZXMgb24gcmVjZW50IHBsYXRmb3Jtcz8NCj4g PiBJZiB5b3Ugd2FudCB0byBmaXggcmVncmVzc2lvbnMsIEkgdGhpbmsgQmVuamFtaW4gaGFzIHN1 Ym1pdHRlZCBhDQo+ID4gcmV2aXNpb24NCj4gPiB0byB1c2Ugb2xkIG1ldGhvZCBtb2RlLCB0aGVy ZSBzaG91bGRuJ3QgYmUgcmVncmVzc2lvbnMgZm9yDQo+ID4gZ25vbWUtc2V0dGluZ3MtZGFlbW9u Lg0KPiA+DQo+ID4gV2hhdCBlbHNlIHdlIHdhbnQgdG8gZG8gaXMgdG8gZml4IHJlZ3Jlc3Npb25z IHJlbGF0ZWQgdG8gc3lzdGVtZCB3aGVuDQo+ID4gd2UgZ28gYmFjayB0byBkZWZhdWx0IG1ldGhv ZCBtb2RlLiBTaW5jZSB0aGVyZSBpcyBubyBpc3N1ZSB3aXRoDQo+ID4gc3lzdGVtZA0KPiA+IDIz MyBhbmQgYWZ0ZXIganVzdCBhcHBseWluZyBhIHNtYWxsIGNoYW5nZSwgc3lzdGVtZCAyMjkgY2Fu IGFsc28gYmUNCj4gPiB3b3JrZWQgYXJvdW5kLCBJIG1lYW4gZHluYW1pY2FsbHkgYWRkL3JlbW92 ZSBpbnB1dCBub2RlIGlzIG5vdA0KPiA+IHN0cmljdGx5DQo+ID4gcmVxdWlyZWQgZm9yIGFjaGll dmluZyBvdXIgcHVycG9zZXMuDQo+ID4NCj4gPiBCdXQgaWYgeW91IHdhbnQgdG8gZml4IG5ldyBp c3N1ZXMgb24gbmV3IHBsYXRmb3Jtcywgd2UgY2FuIGRpc2N1c3MNCj4gPiBmdXJ0aGVyIGFuZCBk ZXRlcm1pbmUgd2hpY2ggcHJvZ3JhbSBzaG91bGQgYmUgY2hhbmdlZCBhbmQgd2hpY2gNCj4gPiBw cm9ncmFtDQo+ID4gaXMgdGhlIGJlc3QgY2FuZGlkYXRlIHRvIHN0b3AgYWxsIHByb2JsZW1zIC0g dGhlIEFDUEkgYnV0dG9uIGRyaXZlcg0KPiA+IG9yDQo+ID4gdGhlIHVzZXIgc3BhY2UuDQo+IA0K PiBJJ20gaGFwcHkgd2l0aCBCZW5qYW1pbidzIHBhdGNoZXMgd2hpY2ggZG9uJ3QgaW50cm9kdWNl IGFueQ0KPiBkZXBlbmRlbmNpZXMgb24gbmV3IHVzZXItc3BhY2UsIGFuZCBkb24ndCByZWx5IG9u IHVuZG9jdW1lbnRlZA0KPiBoZXVyaXN0aWNzLiBXaGF0IHdhcyB0aGUgQVBJIGlzIHN0aWxsIHRo ZSBBUEkuDQoNCkkndmUgcHV0IHRoZW0gaW4gdGhlIG5ldyBzZXJpZXMgYXMgeW91IHdpc2guDQoN CkJ1dCB3aGF0IHlvdSBzYXkgaGVyZSBpcyBub3QgdGhlIHRydXRoLg0KV2l0aCBCZW5qYW1pbidz IHBhdGNoLCB1c2Vyc3BhY2Ugc3RpbGwgbmVlZCB0byBiZSBjaGFuZ2VkIHRvIGJlIGFibGUNCnRv IGtub3cgYW4gaW5wdXQgbm9kZSBpcyBkeW5hbWljYWxseSBjcmVhdGVkIGR1cmluZyBydW50aW1l LiBTbyBpdA0KaXMgc3RpbGwgZGVwZW5kZW50IG9uIG5ldyB1c2VyLXNwYWNlLCBhbmQgZXZlbiBu ZXdlciB0aGFuIHN5c3RlbWQNCjIzMy4NCkl0IHdpbGwgYmUgbm8gZGlmZmVyZW5jZSBieSBqdXN0 IGFza2luZzoNCjEuIHN5c3RlbWQgdG8gbm90IHRvIHJlbHkgb24gIm9wZW4iIGV2ZW50cw0KICAg KHdoaWNoIGhhcyBhbHJlYWR5IGJlZW4gZml4ZWQgaW4gMjMzKS4NCjIuIGRlc2t0b3AgbWFuYWdl cnMgdG8gbm90IHRvIHJlbHkgb24gTElEIHN0YXRlIHRvIGhhbmRsZSBsYXlvdXRzLg0KICAgKHdo aWNoIGlzIHdoYXQgSSdtIGFza2luZyB0byBjaGFuZ2UpLg0KSWYgZGVza3RvcCBtYW5hZ2VycyBz dGlsbCB3YW50IHRvIHJlbHkgb24gTElEIHN0YXRlIHRvIGhhbmRsZSBsYXlvdXRzLA0Ka2VybmVs IGRyaXZlcnMgc3RpbGwgbmVlZCB0byBiZSBjaGFuZ2VkIHRvIHBlcmlvZGljYWxseSByZXBvcnQg X0xJRA0Kc3RhdGUgdG8gaW5wdXQgbGF5ZXIuIEFuZCB0aGF0J3MgYmV5b25kIHdoYXQgQmVuamFt aW4ncyBwYXRjaGVzIGNhbg0KaGFuZGxlLg0KDQpUaGFua3MgYW5kIGJlc3QgcmVnYXJkcw0KTHYN Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752570AbdFVDQU (ORCPT ); Wed, 21 Jun 2017 23:16:20 -0400 Received: from mga11.intel.com ([192.55.52.93]:34787 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752507AbdFVDQQ (ORCPT ); Wed, 21 Jun 2017 23:16:16 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,371,1493708400"; d="scan'208";a="102274330" From: "Zheng, Lv" To: Bastien Nocera CC: Benjamin Tissoires , Peter Hutterer , Lennart Poettering , "Wysocki, Rafael J" , "Rafael J . Wysocki" , "Brown, Len" , Lv Zheng , "linux-acpi@vger.kernel.org" , "systemd-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "linux-input@vger.kernel.org" Subject: RE: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI Thread-Topic: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI Thread-Index: AQHS2wd01O/IlIfVsk2vy8j9OHBM16IYiNMAgAmUZoCAAzAyYP//vNyAgACPuZD//4QFgIABmvZA///tuAAAEOsxgP//haIA//9u+qCAAKDZAP/7QTDAgApQYoD//zJqoABlov0A//5gvjA= Date: Thu, 22 Jun 2017 03:16:09 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E886CED2DAB@SHSMSX101.ccr.corp.intel.com> References: <20170601184632.2980-1-benjamin.tissoires@redhat.com> <20170607074848.GE27006@gardel-login> <20170613100617.GD29589@mail.corp.redhat.com> <1AE640813FDE7649BE1B193DEA596E886CED0386@SHSMSX101.ccr.corp.intel.com> <20170615064715.GA6195@jelly> <1AE640813FDE7649BE1B193DEA596E886CED047B@SHSMSX101.ccr.corp.intel.com> <20170615075755.GA10001@jelly> <1AE640813FDE7649BE1B193DEA596E886CED0A03@SHSMSX101.ccr.corp.intel.com> <20170616072322.GL5085@mail.corp.redhat.com> <1AE640813FDE7649BE1B193DEA596E886CED0AC1@SHSMSX101.ccr.corp.intel.com> <20170616080950.GM5085@mail.corp.redhat.com> <1AE640813FDE7649BE1B193DEA596E886CED0C5E@SHSMSX101.ccr.corp.intel.com> <33C872C7-EFB2-4CA0-8CAD-8B6E8916180C@hadess.net> <1AE640813FDE7649BE1B193DEA596E886CED1419@SHSMSX101.ccr.corp.intel.com> <1497910127.2559.1.camel@hadess.net> <1AE640813FDE7649BE1B193DEA596E886CED1C41@SHSMSX101.ccr.corp.intel.com> <1498040588.2559.30.camel@hadess.net> In-Reply-To: <1498040588.2559.30.camel@hadess.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTk4MzAwZmUtMjhiOC00ODEzLTljZmUtMzQ1YTY3YWFhOTZiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik1vcFIwN1prQmxTYlhDZEhIWWtCYVVoRjk1eWd0bTUxVGZRUUE5OXhaUlk9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v5M3GeV6002991 Hi, > From: Bastien Nocera [mailto:hadess@hadess.net] > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI > > On Tue, 2017-06-20 at 02:45 +0000, Zheng, Lv wrote: > > Hi, > > > > > From: Bastien Nocera [mailto:hadess@hadess.net] > > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable > > > LID switch exported by ACPI > > > > > > On Mon, 2017-06-19 at 01:43 +0000, Zheng, Lv wrote: > > > > > > > > > > > > > > If you implement it in such a way that GNOME settings daemon > > > > > behaves weirdly, you'll get my revert > > > > > request in the mail. Do. Not. Ever. Lie. > > > > > > > > First, I don't know what should be reverted... > > > > I have 2 solutions here for review, and Benjamin has 1. > > > > And none of them has been upstreamed. > > > > We are just discussing. > > > > > > The discussion is getting tiring quite frankly. We've been over > > > this > > > for nearly a year now, and with no end in sight. > > > > We have concerns to introduce too complicated logics to such a > > simple button driver especially the logics are related to platform > > firmware, input ABI and user space behaviors. > > > > I understand the situation. > > Anyway this shouldn't be a big deal. > > Let's prepare a smarter series to collect all fixes and solutions > > with runtime configurables and get that to the end users. > > So that we can figure out which is the simplest solution. > > > > But before that, let me ask several questions about gnome-setting- > > deamon. > > > > > > > > > However we need to get 1 of them upstreamed in next cycle. > > > > > > > > I think users won't startup gnome-setting-daemon right after > > > > resume. > > > > It should have already been started. > > > > > > > > There is only 1 platform may see delayed state update after > > > > resume. > > > > Let's see if there is a practical issue. > > > > 1. Before suspend, the "lid state" is "close", and > > > > 2. After resume, the state might remain "close" for a while > > > > Since libinput won't deliver close to userspace, > > > > and gnome-setting-daemon listens to key switches, there is no > > > > wrong behavior. > > > > > > It doesn't. It listens to UPower, which tells user-space whether > > > there > > > is a lid switch, and whether it's opened or closed. > > > > Thanks for the information. > > However I don't see differences here. > > > > > > > > > 3. Then after several seconds, "open" arrives. > > > > gnome-setting-daemon re-arrange monitors and screen layouts in > > > > response to the new event. > > > > > > Just how is anyone supposed to know that there is an event coming? > > > > Will UPower deliver EV_SW key events to gnome-setting-daemon? > > > > > > > > > So there is no problem. IMO, there is no need to improve for > > > > post- > > > > resume case. > > > > > > > > Users will just startup gnome-setting-daemon once after boot. > > > > And it's likely that when it is started, the state is correct. > > > > > > You cannot rely on when gnome-settings-daemon will be started to > > > make > > > *any* decision. Certainly not decisions on how the kernel should > > > behave. > > > > My bad wording, I just meant: > > When gnome-settings-daemon is started is not related to what we are > > discussing. > > > > Do you want to fix regressions? > > Or you want to fix new issues on recent platforms? > > If you want to fix regressions, I think Benjamin has submitted a > > revision > > to use old method mode, there shouldn't be regressions for > > gnome-settings-daemon. > > > > What else we want to do is to fix regressions related to systemd when > > we go back to default method mode. Since there is no issue with > > systemd > > 233 and after just applying a small change, systemd 229 can also be > > worked around, I mean dynamically add/remove input node is not > > strictly > > required for achieving our purposes. > > > > But if you want to fix new issues on new platforms, we can discuss > > further and determine which program should be changed and which > > program > > is the best candidate to stop all problems - the ACPI button driver > > or > > the user space. > > I'm happy with Benjamin's patches which don't introduce any > dependencies on new user-space, and don't rely on undocumented > heuristics. What was the API is still the API. I've put them in the new series as you wish. But what you say here is not the truth. With Benjamin's patch, userspace still need to be changed to be able to know an input node is dynamically created during runtime. So it is still dependent on new user-space, and even newer than systemd 233. It will be no difference by just asking: 1. systemd to not to rely on "open" events (which has already been fixed in 233). 2. desktop managers to not to rely on LID state to handle layouts. (which is what I'm asking to change). If desktop managers still want to rely on LID state to handle layouts, kernel drivers still need to be changed to periodically report _LID state to input layer. And that's beyond what Benjamin's patches can handle. Thanks and best regards Lv