| commit | d4ac3ccecf5d66610be3046c977eac83b2c190ca | |
| author | Carlos Corbacho <cathectic@gmail.com> | |
| Tue, 30 Oct 2007 01:22:06 +0000 (30 01:22 +0000) | ||
| committer | Carlos Corbacho <cathectic@gmail.com> | |
| Tue, 30 Oct 2007 01:22:06 +0000 (30 01:22 +0000) | ||
| tree | cba2bbf2ba2e60b793f92a2dcf1a9d11d7225529 | treesnapshot (tar.gz zip) |
| parent | dab4bb0a227a8fb2842a1028a2a47acb35687779 | commitdiff |
wmi-acer: Rewrite event handling
Currently, WMI doesn't do anything with received events. We could
export them to userspace (via proc and netlink) - Unfortunately, this
is not really much use. Also, we can't export back the data from _WED
this way (as specified by the spec).
Instead, we now allow WMI drivers to register a notify handler with
WMI, as the meaning of an event will be specific to a given WMI mapper.
When a Notify() is sent to PNP0C14, WMI will now:
A) Call _WED with the event fired
B) Pass the results of _WED back up to the handler registered with
WMI.
It is then up to the handler function of the registered driver to
deal with the event.
Currently, WMI doesn't do anything with received events. We could
export them to userspace (via proc and netlink) - Unfortunately, this
is not really much use. Also, we can't export back the data from _WED
this way (as specified by the spec).
Instead, we now allow WMI drivers to register a notify handler with
WMI, as the meaning of an event will be specific to a given WMI mapper.
When a Notify() is sent to PNP0C14, WMI will now:
A) Call _WED with the event fired
B) Pass the results of _WED back up to the handler registered with
WMI.
It is then up to the handler function of the registered driver to
deal with the event.
| wmi-acer.c | diffblobblamehistory | |
| wmi-acer.h | diffblobblamehistory |