search for: acpi_lid_notifier_register

...lid_notify() doesn't use the provided value but calls > acpi_lid_open(), but this is something that can be solved in > https://bugs.freedesktop.org/show_bug.cgi?id=100923, when the > situation clarifies. The snarky reply here might be that we're just following the documentation of acpi_lid_notifier_register(), acpi_lid_open(), and friends. ;) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center

On Mon, May 15, 2017 at 10:42 AM, Jani Nikula <jani.nikula at linux.intel.com> wrote: > On Mon, 15 May 2017, Benjamin Tissoires <benjamin.tissoires at gmail.com> wrote: >> I'll answer everything in the other thread, where there are slightly >> more other points raised: https://lkml.org/lkml/2017/5/15/10 > > If you are discussing changes impacting i915, please

...n instead of returning the lid state upon the last _LID evaluation. In order to have acpi lid event notifier API compliant to the above mentioned both "buggy" and "nonbuggy" implementation. The ensured lid event model interface should be: 1. Lid event notifier listeners invokes acpi_lid_notifier_register(). 2. And in the callback, uses _LID return value. This is also the only possible way to combine "receiving lid notify" and "evaluate _LID" into 1 single atomic operation. So I trend to remove acpi_lid_open() and enforce the new API. As a conclusion, PATCH 4-5 1. makes a hidde...

...he lid > state upon the last _LID evaluation. > > In order to have acpi lid event notifier API compliant to the above mentioned both "buggy" and "nonbuggy" implementation. > The ensured lid event model interface should be: > 1. Lid event notifier listeners invokes acpi_lid_notifier_register(). > 2. And in the callback, uses _LID return value. > This is also the only possible way to combine "receiving lid notify" and "evaluate _LID" into 1 single atomic operation. > > So I trend to remove acpi_lid_open() and enforce the new API. > > As a conclusion...

On Tue, May 9, 2017 at 9:02 AM, Lv Zheng <lv.zheng at intel.com> wrote: > Since notification side has been changed to always notify kernel listeners > using _LID returning value. Now listeners needn't invoke acpi_lid_open(), > it should use a spec suggested control method lid device usage model: > register lid notification and use the notified value instead, which is the >

...e last _LID evaluation. > > > > In order to have acpi lid event notifier API compliant to the above mentioned both "buggy" and > "nonbuggy" implementation. > > The ensured lid event model interface should be: > > 1. Lid event notifier listeners invokes acpi_lid_notifier_register(). > > 2. And in the callback, uses _LID return value. > > This is also the only possible way to combine "receiving lid notify" and "evaluate _LID" into 1 > single atomic operation. > > > > So I trend to remove acpi_lid_open() and enforce the new API....

...on. >> > >> > In order to have acpi lid event notifier API compliant to the above mentioned both "buggy" and >> "nonbuggy" implementation. >> > The ensured lid event model interface should be: >> > 1. Lid event notifier listeners invokes acpi_lid_notifier_register(). >> > 2. And in the callback, uses _LID return value. >> > This is also the only possible way to combine "receiving lid notify" and "evaluate _LID" into 1 >> single atomic operation. >> > >> > So I trend to remove acpi_lid_open() and e...