On 05/26/2010 03:51 PM, Gustavo Sverzut Barbieri wrote:
> 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).
Ok, let me try to clear this up a little then:
2 event handlers get added for one event (E_EVENT_ACPI_AC_ADAPTER).
One handler is supposed to handle "plugged in", the other "unplugged",
but both use the same E_EVENT_ACPI_AC_ADAPTER.
Now, the event comes in (adapter gets unplugged).
e_acpi receives the event via ecore_event_handler twice because of the
two bindings (plugged & unplugged), but really only one event occured
("plugged")....so "plugged" event ends up getting called twice.
>
> 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.
>
This is where the "rub" might be ... all events are handled by the same
callback. Inside the e_acpi_cb_event, we check for any bindings that
relate to the event, and call the bindings....Perhaps I just need to
rethink that event callback stuff ....
dh
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
