Hi all, I ran into a snafu wrt acpi stuff. Keep in mind that some of the things mentioned here are not in svn yet. I'll try to iterate the short version:
acpi bindings get added to e_config. When e_acpi is initialized, we create event handlers for the events specified in e_config so that when the event fires we can call any existing binding(s) (ex: When Adapter is unplugged, dim the screen. So we create a handler for the acpi_ac_adapter event). In e_config, we will potentially have two acpi_ac_adapter events...one for plugged (dim the screen), one for unplugged (undim the screen). The problem that I ran into is this: During acpi_init, when creating the event_handlers for ac_adapter, two event_handlers get created (plugged & unplugged). The problem is that because 2 handlers get created, when the ac_adapter changes, the events are firing twice :( (ex: ac_adapter is unplugged, event fires to dim the screen), but because 2 event handlers were created the event gets fired again....so now we are getting two calls to dim the screen, even tho the second "handler" is really for undim. The second handler is really for when ac_adapter gets plugged back in, but due to the nature of how devices are handled in acpi, we don't have separate E_EVENT_ACPI's for adapter. This could be fixed by adding/changing E_EVENT_ACPI_AC_ADAPTER_PLUGGED/UNPLUGGED, but this would also require E_EVENT_ACPI's to be created for every possible device state: (ie: battery_charging, battery_removed, etc, etc). Obviously, I am against this approach as we really have no way of knowing all the possible states that any given device supports...hence why I took the generic approach of using one E_EVENT_ACPI for a given device, and passing it some params that could then be acted on (ie: when the ac_adapter event fires, it's "params" will be 0 or 1 depending on adapter state, lid event has "params" of 0 or 1 for open/closed, etc, etc). What I would like to do is add an ecore_event_handler_type_get function because the Ecore_Event_Handler struct is not exposed via API. Reasoning here is: we add the event handlers to a list during init, so what I could do is before adding those handlers to the list, I could iterate the list and check that a handler for that type has already been added, and skip it, etc, etc. Would anyone be against the addition of ecore_event_handler_type_get ?? If so, are there any thoughts on a better approach to this problem ?? dh ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
