From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Tissoires Subject: Re: [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI Date: Fri, 16 Jun 2017 10:09:50 +0200 Message-ID: <20170616080950.GM5085@mail.corp.redhat.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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <1AE640813FDE7649BE1B193DEA596E886CED0AC1@SHSMSX101.ccr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: systemd-devel-bounces@lists.freedesktop.org Sender: "systemd-devel" To: "Zheng, Lv" Cc: "Brown, Len" , "systemd-devel@lists.freedesktop.org" , "linux-acpi@vger.kernel.org" , "Wysocki, Rafael J" , "Rafael J . Wysocki" , "linux-kernel@vger.kernel.org" , Lv Zheng , Lennart Poettering , "linux-input@vger.kernel.org" List-Id: linux-acpi@vger.kernel.org T24gSnVuIDE2IDIwMTcgb3IgdGhlcmVhYm91dHMsIFpoZW5nLCBMdiB3cm90ZToKPiBIaSwgQmVu amFtaW4KPiAKPiBMZXQgbWUganVzdCBzYXkgc29tZXRoaW5nIG9uZSBtb3JlIHRpbWUuCj4gCj4g PiBGcm9tOiBCZW5qYW1pbiBUaXNzb2lyZXMgW21haWx0bzpiZW5qYW1pbi50aXNzb2lyZXNAcmVk aGF0LmNvbV0KCltzbmlwXQo+ID4gPiA+ID4KPiA+ID4gPiA+IFdlIGNhbiBzZWU6Cj4gPiA+ID4g PiAibG9naW5kIiBoYXMgYWxyZWFkeSBpbXBsZW1lbnRlZCBhIHRpbWVvdXQsIGFuZCB3aWxsIG5v dCByZXNwb25kIGxpZCBzdGF0ZQo+ID4gPiA+ID4gdW5sZXNzIGl0IGNhbiBiZSBzdGFibGUgd2l0 aGluIHRoaXMgdGltZW91dCBwZXJpb2QuCj4gPiA+ID4gPiBJJ20gbm90IGFuIGV4cGVydCBvZiBs b2dpbmQsIG1heWJlIHRoaXMgaXMgYmVjYXVzZSBvZiAiSG9sZE9mZlRpbWVvdXRTZWMiPwo+ID4g PiA+ID4KPiA+ID4gPiA+IEkgZmVlbCAicmVtb3ZpbmcgdGhlIGlucHV0IG5vZGUgZm9yIGEgcGVy aW9kIHdoZXJlIGl0cyBzdGF0ZSBpcyBub3QgdHJ1c3RmdWwiCj4gPiA+ID4gPiBpcyB0ZWNobmlj YWxseSBpZGVudGljYWwgdG8gdGhpcyBtZWNoYW5pc20uCj4gPiA+ID4KPiA+ID4gPiBidXQgeW91 J2QgYmUgbWFraW5nIGtlcm5lbCBwb2xpY3kgYmFzZWQgb24gb25lIHVzZXJzcGFjZSBpbXBsZW1l bnRhdGlvbi4KPiA+ID4gPiBlLmcuIGxpYmlucHV0IGRvZXNuJ3QgaGF2ZSBhIHRpbWVvdXQgcGVy aW9kLCBpdCBhc3N1bWVzIHRoZSBzdGF0ZSBpcwo+ID4gPiA+IGNvcnJlY3Qgd2hlbiBhbiBpbnB1 dCBub2RlIGlzIHByZXNlbnQuCj4gPiA+Cj4gPiA+IERvIHlvdSBzZWUgcHJhY3RpY2FsIGlzc3Vl cz8KPiA+IAo+ID4gWWVzLCBsaWJpbnB1dCBjYW4ndCByZWx5IG9uIHRoZSBMSUQgc3dpdGNoIGlu Zm9ybWF0aW9uIHRvIGRpc2FibGUKPiA+IHRvdWNocGFkcy90b3VjaHNjcmVlbnMgdGhhdCBhcmUg cG90ZW50aWFsbHkgc2VuZGluZyBmYWxzZSBwb3NpdGl2ZS4KPiAKPiAicG90ZW50aWFsIiBkb2Vz bid0IG1lYW4gInByYWN0aWNhbCIsIHJpZ2h0PwoKSSB3YXMgdXNpbmcgcG90ZW50aWFsIHRvIHNh eSB0aGF0IHNvbWUgYWN0dWFsIGRldmljZXMgYXJlIHNlbmRpbmcKcmlnaHRmdWwgc3RhdGVzLCB3 aGlsZSBvdGhlcnMgYXJlIG5vdCAod2UgYWxyZWFkeSBuYW1lZCB0aGVtIGEgbG90IGluCnRob3Nl IGNvdW50bGVzcyB0aHJlYWRzKS4gU28gcG90ZW50aWFsIGhlcmUgaXMgZnJvbSBhIHVzZXIgc3Bh Y2UKcGVyc3BlY3RpdmUgd2hlcmUgeW91IGFyZSBub3Qgc3VyZSBpZiB0aGUgc3RhdGUgaXMgcmVs aWFibGUgb3Igbm90CihnaXZlbiB3ZSBjdXJyZW50bHkgZG9uJ3QgaGF2ZSB0aGlzIGluZm9ybWF0 aW9uIGFib3V0IHJlbGlhYmlsaXR5KS4KCj4gQWZ0ZXIgYXBwbHlpbmcgbXkgbGFzdCB2ZXJzaW9u Lgo+IFRoZXJlIGFyZSBubyBmYWxzZS1wb3NpdGl2ZXMgSU1PLgo+IFRoZXJlIGFyZSBvbmx5IGRl bGF5cyBmb3IgdGhlIHJlbGlhYmxlIGtleSBldmVudHMuCj4gICAgICAgICAgICAgICAgXl5eXl5e Cj4gV2hpbGUgdGhlICJkZWxheSIgaXMgdmVyeSBjb21tb24gaW4gY29tcHV0aW5nIHdvcmxkLgoK Tm8sIGlmIHRoZXJlIGlzIGEgZGVsYXksIHRoZXJlIGlzIGEgZmFsc2UgcG9zaXRpdmUsIGJlY2F1 c2UgdGhlIGluaXRpYWwKc3RhdGUgaXMgd3Jvbmcgd2l0aCByZXNwZWN0IHRvIHRoZSBkZXZpY2Ug cGh5c2ljYWwgc3RhdGUuCgo+IAo+ID4gPiBBZnRlciByZXN1bWUsIFNXX0xJRCBzdGF0ZSBjb3Vs ZCByZW1haW4gdW5yZWxpYWJsZSAiY2xvc2UiIGZvciBhIHdoaWxlLgo+ID4gCj4gPiBUaGlzIGlz IG5vdCBhbiBvcHRpb24uIEl0IGlzIG5vdCBwYXJ0IG9mIHRoZSBwcm90b2NvbCwgaGF2aW5nIGFu Cj4gPiB1bnJlbGlhYmxlIHN0YXRlLgo+ID4gCj4gPiA+IEJ1dCB0aGF0J3MganVzdCBhIGtpbmQg b2YgZGVsYXkgaGFwcGVucyBpbiBhbGwgY29tcHV0aW5nIHByb2dyYW1zLgo+ID4gPiBJIHN1cHBv c2UgYWxsIHBvd2VyIG1hbmFnaW5nIHByb2dyYW1zIGhhdmUgYWxyZWFkeSBoYW5kbGVkIHRoYXQu Cj4gPiA+IEkgY29uZmlybWVkIG5vIGJyZWFrYWdlIGZvciBzeXN0ZW1kIDIzMy4KPiA+ID4gRm9y IHN5c3RlbWQgMjI5LCBpdCBjYW5ub3QgaGFuZGxlIGl0IHdlbGwgZHVlIHRvIGJ1Z3MuCj4gPiA+ IEJ1dCBteSBsYXRlc3QgcGF0Y2ggc2VyaWVzIGhhcyB3b3JrZWQgdGhlIGJ1ZyBhcm91bmQuCj4g PiA+IFNvIEkgZG9uJ3Qgc2VlIGFueSBicmVha2FnZSByZWxhdGVkIHRvIHBvc3QtcmVzdW1lIGlu Y29ycmVjdCBzdGF0ZSBwZXJpb2QuCj4gPiA+IERvIHlvdSBzZWUgcHJvYmxlbXMgdGhhdCBteSB0 ZXN0cyBoYXZlbid0IGNvdmVyZWQ/Cj4gPiAKPiA+IFRoZSBwcm9ibGVtcyBhcmUgdGhhdCB5b3Ug YXJlIG5vdCBmb2xsb3dpbmcgdGhlIHByb3RvY29sLiBBbmQgaWYgc3lzdGVtZAo+ID4gMjMzIHdv cmtzIGFyb3VuZCBpdCwgdGhhdCdzIGdvb2QsIGJ1dCBzeXN0ZW1kIGlzIG5vdCB0aGUgb25seSBs aXN0ZW5lcgo+ID4gb2YgdGhlIExJRCBzd2l0Y2ggaW5wdXQgbm9kZSwgYW5kIHlvdSBhcmUgc3Rp bGwgYnJlYWtpbmcgdGhvc2UgYnkKPiA+IHJlZnVzaW5nIHRvIGZvbGxvdyB0aGUgc3BlY2lmaWNh dGlvbiBvZiB0aGUgZXZkZXYgcHJvdG9jb2wuCj4gCj4gQXMgeW91IGFyZSB0YWxraW5nIGFib3V0 IHByb3RvY29sLCBsZXQgbWUganVzdCBhc2sgb25jZS4KPiAKPiBJbiBjb21wdXRpbmcgd29ybGQs Cj4gMS4gZGVsYXkgaXMgdmVyeSBjb21tb24KPiAgICBUaGVyZSBhcmUgYnVzIHR1cm5hcm91bmQs IG5ldHdvcmsgdHVybmFyb3VuZCwgLi4uCj4gICAgRXZlbiBtZWFzdXJlbWVudCBpdHNlbGYgaGFz IGRlbGF5IGRlc2NyaWJlZCBieSBTaGFubm9uIHNhbXBsaW5nLgo+ICAgIFNob3VsZCB0aGUgZGVs YXkgYmUgYSBwYXJ0IG9mIHRoZSBwcm90b2NvbD8KClBsZWFzZSwgeW91IGFyZSBlaXRoZXIgdHJv bGxpbmcgb3IganVzdCBraWRkaW5nLiBJZiB0aGVyZSBhcmUgZGVsYXlzIGluCnRoZSAiY29tcHV0 aW5nIHdvcmxkIiwgdGhlc2UgaGFzIHRvIGJlIGhhbmRsZWQgYnkgdGhlIGtlcm5lbCwgYW5kIG5v dApleHBvcnRlZCB0byB0aGUgdXNlciBzcGFjZSBpZiB0aGUga2VybmVsIHByb3RvY29sIHNheXMg dGhhdCB0aGUgc3RhdGUgaXMKcmVsaWFibGUuCgo+IDIuIHByb2dyYW1zIGFyZSBhY3RpbmcgYWNj b3JkaW5nIHRvIHJ1bGVzICh3ZSBjYWxsIHN0YXRlIG1hY2hpbmVzKQo+ICAgIFN0YXRlcyBhcmUg b25seSBkZXRlcm1pbmVkIGFmdGVyIG1lYXN1cmVtZW50IChsaWtlICJxdWFudHVtIHN0YXRlcyIp Cj4gICAgSSBoYXZlIFNjaHJvZWRpbmdlcidzIGNhdCBpbiBteSBtaW5kLgo+ICAgIEV2ZW50cyBh cmUgZGV0ZXJtaW5lZCBhcyB0aGV5IGFsd2F5cyBvY2N1ciBhZnRlciBtZWFzdXJlbWVudCB0byB0 cmlnZ2VyICJxdWFudHVtIGp1bXBzIi4KPiAgICBTbyBmb3IgRVZfU1cgcHJvdG9jb2wsCj4gICAg U2hvdWxkIHByb2dyYW1zIHJlbHkgb24gdGhlIHJlbGlhYmxlICJxdWFudHVtIGp1bXBzIiwKPiAg ICBPciBzaG91bGQgcHJvZ3JhbXMgcmVseSBvbiB0aGUgdW5yZWxpYWJsZSAicXVhbnR1bSBzdGF0 ZXMiPwoKTm8gY29tbWVudHMsIHRoaXMgd29uJ3QgZ2V0IHVzIGFueXdoZXJlLgoKPiAKPiBJIHRo aW5rIG1vc3QgVUkgcHJvZ3JhbXMgY2FyZSBubyBhYm91dCBzdGF0ZSBzdG9yZWQgaW4gdGhlIGlu cHV0IG5vZGUsCj4gdGhleSBvbmx5IHJlY2VpdmUgZXZlbnRzIHJhaXNlZCBmcm9tIHRoZSBpbnB1 dCBub2RlLgoKQnVsbHNoaXQuIFdoZW4geW91IGxhdW5jaCBzdWNoIGEgcHJvZ3JhbSwgeW91IG5l ZWQgdG8gcXVlcnkgdGhlIHN0YXRlCmJlY2F1c2UgeW91IHdvbid0IHJlY2VpdmUgdGhlIGV2ZW50 IHRoYXQgaGFwcGVuZWQgd2F5IGJlZm9yZSB0aGUgbGF1bmNoLgoKPiBXaHkgc2hvdWxkIHRoZSBr ZXJuZWwgZXhwb3J0IGEgZmFkZS1pbi9mYWRlLW91dCBpbnB1dCBub2RlIHRvIHRoZSBVSSBwcm9n cmFtcyBhbmQgYXNrIHRoZW0gdG8gY2hhbmdlPwo+IAo+IFRoZSBvbmx5IHByb2dyYW0gdGhhdCBj YXJlcyBhYm91dCB0aGUgc3RhdGUgc3RvcmVkIGluIHRoZSBpbnB1dCBub2RlIGlzIGxpYmlucHV0 Lgo+IFNvIHdoeSBzaG91bGQgZXZlcnkgdXNlciBwcm9ncmFtIGJlIGNoYW5nZWQgdG8gbWFrZSBs aWJpbnB1dCBlYXNpZXI/CgpObywgYWxsIHByb2dyYW0gdGhhdCBsaXN0ZW4gdG8gTElEIHN3aXRj aGVzIGlucHV0IG5vZGVzIGNhcmUgYWJvdXQgdGhlCnN0YXRlLiBXZSBhbHJlYWR5IHRvbGQgeW91 IHRoYXQsIHlvdSBqdXN0IGRvbid0IGxpc3RlbjoKCi0gc3lzdGVtZCBjYXJlcyBhYm91dCB0aGUg c3RhdGUgYXMgaXQgZG9lcyBwb2xsaW5nIG9uIHRoZSBpbnB1dCBub2RlIGluCiAgY2FzZSBpdCBt aXNzZXMgYW4gZXZlbnQKLSBsaWJpbnB1dCBjYXJlcyBhYm91dCB0aGUgc3RhdGUgYXMgcHJldmlv dXNseSBtZW50aW9uZWQKLSBnbm9tZS1zZXR0aW5nLWRhZW1vbnMgY2FyZXMgYWJvdXQgdGhlIHN0 YXRlIGdpdmVuIGl0IGRlY2lkZXMgd2hldGhlcgogIG9yIG5vdCBsaWdodGluZyB1cCB0aGUgbW9u aXRvcnMgZGVwZW5kaW5nIG9uIHRoZSBzdGF0ZS4gQW5kIGlmIHlvdQogIHJlbGF1bmNoIHRoZSBk YWVtb24sIGl0J2xsIHF1ZXJ5IHRoZSBzdGF0ZSB0byBkZWNpZGUgd2hhdCBpcyB0aGUgYmVzdAog IGFycmFuZ2VtZW50IGZvciB0aGUgc2NyZWVucwotIEtERSBzaG91bGQgZG8gdGhlIHNhbWUgKGFz IGl0IGlzIG5vdCBhIGRhZW1vbiB0aGF0IGNhbiBjYXRjaCBhbnkKICBldmVudHMpCgpBbmQgSSBy ZWFsbHkgZG9uJ3Qga25vdyB3aHkgSSBhbSB0ZWxsaW5nIHlvdSB0aGF0LiBUaGUgcnVsZSBpcyBz aW1wbGU6CnRoZXJlIGlzIGEga2VybmVsIHByb3RvY29sLCB3aGljaCBpcyBhIGNvbnRyYWN0IGJl dHdlZW4gdGhlIGtlcm5lbCBhbmQKdGhlIHVzZXIgc3BhY2UuIFdpdGggc3VjaCAiZGVsYXlzIiB0 aGlzIGFjcGkvYnV0dG9uLmMgZHJpdmVyIGRvZXNuJ3QKZm9sbG93IHRoZSBwcm90b2NvbC4gU28g aXQncyBhIGJ1Zy4gRW5kIG9mIHRoZSBzdG9yeS4KCklmIHlvdSB3YW50IHRvIGhhdmUgYSB0cmFu c2llbnQgc3RhdGUgd2l0aCBkZWxheSBvciBzdWNoLCBmZWVsIGZyZWUgdG8Kd3JpdGUgZG93biBh IHByb3RvY29sIGZvciBzdWNoIHRyaS1zdGF0ZSBzd2l0Y2gsIGJ1dCBJIGRvdWJ0IHRoaXMgd2ls bApiZSBhY2NlcHRlZCBieSB0aGUgaW5wdXQgbWFpbnRhaW5lci4KCkNoZWVycywKQmVuamFtaW4K Cj4gCj4gQ2hlZXJzLAo+IEx2Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCnN5c3RlbWQtZGV2ZWwgbWFpbGluZyBsaXN0CnN5c3RlbWQtZGV2ZWxAbGlzdHMu ZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlz dGluZm8vc3lzdGVtZC1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752813AbdFPIKH (ORCPT ); Fri, 16 Jun 2017 04:10:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55138 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752352AbdFPIKC (ORCPT ); Fri, 16 Jun 2017 04:10:02 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BAAE35D5E9 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=benjamin.tissoires@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BAAE35D5E9 Date: Fri, 16 Jun 2017 10:09:50 +0200 From: Benjamin Tissoires To: "Zheng, Lv" Cc: 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 Message-ID: <20170616080950.GM5085@mail.corp.redhat.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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1AE640813FDE7649BE1B193DEA596E886CED0AC1@SHSMSX101.ccr.corp.intel.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 16 Jun 2017 08:10:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Jun 16 2017 or thereabouts, Zheng, Lv wrote: > Hi, Benjamin > > Let me just say something one more time. > > > From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com] [snip] > > > > > > > > > > We can see: > > > > > "logind" has already implemented a timeout, and will not respond lid state > > > > > unless it can be stable within this timeout period. > > > > > I'm not an expert of logind, maybe this is because of "HoldOffTimeoutSec"? > > > > > > > > > > I feel "removing the input node for a period where its state is not trustful" > > > > > is technically identical to this mechanism. > > > > > > > > but you'd be making kernel policy based on one userspace implementation. > > > > e.g. libinput doesn't have a timeout period, it assumes the state is > > > > correct when an input node is present. > > > > > > Do you see practical issues? > > > > Yes, libinput can't rely on the LID switch information to disable > > touchpads/touchscreens that are potentially sending false positive. > > "potential" doesn't mean "practical", right? I was using potential to say that some actual devices are sending rightful states, while others are not (we already named them a lot in those countless threads). So potential here is from a user space perspective where you are not sure if the state is reliable or not (given we currently don't have this information about reliability). > After applying my last version. > There are no false-positives IMO. > There are only delays for the reliable key events. > ^^^^^^ > While the "delay" is very common in computing world. No, if there is a delay, there is a false positive, because the initial state is wrong with respect to the device physical state. > > > > After resume, SW_LID state could remain unreliable "close" for a while. > > > > This is not an option. It is not part of the protocol, having an > > unreliable state. > > > > > But that's just a kind of delay happens in all computing programs. > > > I suppose all power managing programs have already handled that. > > > I confirmed no breakage for systemd 233. > > > For systemd 229, it cannot handle it well due to bugs. > > > But my latest patch series has worked the bug around. > > > So I don't see any breakage related to post-resume incorrect state period. > > > Do you see problems that my tests haven't covered? > > > > The problems are that you are not following the protocol. And if systemd > > 233 works around it, that's good, but systemd is not the only listener > > of the LID switch input node, and you are still breaking those by > > refusing to follow the specification of the evdev protocol. > > As you are talking about protocol, let me just ask once. > > In computing world, > 1. delay is very common > There are bus turnaround, network turnaround, ... > Even measurement itself has delay described by Shannon sampling. > Should the delay be a part of the protocol? Please, you are either trolling or just kidding. If there are delays in the "computing world", these has to be handled by the kernel, and not exported to the user space if the kernel protocol says that the state is reliable. > 2. programs are acting according to rules (we call state machines) > States are only determined after measurement (like "quantum states") > I have Schroedinger's cat in my mind. > Events are determined as they always occur after measurement to trigger "quantum jumps". > So for EV_SW protocol, > Should programs rely on the reliable "quantum jumps", > Or should programs rely on the unreliable "quantum states"? No comments, this won't get us anywhere. > > I think most UI programs care no about state stored in the input node, > they only receive events raised from the input node. Bullshit. When you launch such a program, you need to query the state because you won't receive the event that happened way before the launch. > Why should the kernel export a fade-in/fade-out input node to the UI programs and ask them to change? > > The only program that cares about the state stored in the input node is libinput. > So why should every user program be changed to make libinput easier? No, all program that listen to LID switches input nodes care about the state. We already told you that, you just don't listen: - systemd cares about the state as it does polling on the input node in case it misses an event - libinput cares about the state as previously mentioned - gnome-setting-daemons cares about the state given it decides whether or not lighting up the monitors depending on the state. And if you relaunch the daemon, it'll query the state to decide what is the best arrangement for the screens - KDE should do the same (as it is not a daemon that can catch any events) And I really don't know why I am telling you that. The rule is simple: there is a kernel protocol, which is a contract between the kernel and the user space. With such "delays" this acpi/button.c driver doesn't follow the protocol. So it's a bug. End of the story. If you want to have a transient state with delay or such, feel free to write down a protocol for such tri-state switch, but I doubt this will be accepted by the input maintainer. Cheers, Benjamin > > Cheers, > Lv