Hi! I know people had questions with the structure/uses of the events in the previous versions of this patch. Does this clear things up?
Thanks, Nick On Wed, Apr 3, 2019 at 6:31 PM Nick Crews <ncr...@chromium.org> wrote: > > The Wilco Embedded Controller can create custom events that > are not handled as standard ACPI objects. These events can > contain information about changes in EC controlled features, > such as errors and events in the dock or display. For example, > an event is triggered if the dock is plugged into a display > incorrectly. These events are needed for telemetry and > diagnostics reasons, and for possibly alerting the user. > > These events are triggered by the EC with an ACPI Notify(0x90), > and then the BIOS reads the event buffer from EC RAM via an > ACPI method. When the OS receives these events via ACPI, > it passes them along to this driver. The events are put into > a queue which can be read by a userspace daemon via a char device > that implements read() and poll(). The char device will appear at > /dev/wilco_event{n}, where n is some small non-negative integer, > starting from 0. Standard ACPI events such as the battery getting > plugged/unplugged can also come through this path, but they are > dealt with via other paths, and are ignored here. > > To test, you can tail the binary data with > $ cat /dev/wilco_event0 | hexdump -ve '1/1 "%x\n"' > and then create an event by pressing fn+Esc. > > v3 changes: > - Made commit description more accurate and useful. > - Added an exclusive lock for opening the char device, > so only one userspace process can read events at a time. > > Signed-off-by: Nick Crews <ncr...@chromium.org>