On Wed, 26 May 2010 16:00:31 -0400 Christopher Michael <cpmicha...@comcast.net>
said:
i'm with gustavo. i don't get what the problem is. this kind of thing happens
all over the place - 1 event id has and event struct with multiple fields. some
handlers just don't care about the event if some fields are not set - so the
event handler simply checks and if the event is not relevant - then it just
instantly returns 1 - passing the event along to the next handler.
> 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
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
