On Wed, May 26, 2010 at 3:45 PM, Christopher Michael <cpmicha...@comcast.net> wrote: > 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 ??
I'm not sure I understand what you mean. This situation should be similar to others we already have, like ECORE_EVENT_SIGNAL_EXIT that carries in the event structure the reason of the event (see struct _Ecore_Event_Signal_Exit). I see no problem registering twice the same event, just the callbacks need to handle it differently, like for plug you use func1 and for unplug you use func2, they would do: if (!ev->plug) return and if (ev->plug) return respectively. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
