Turns out this is slightly tricky to do.

GdkFilterFunc is defined like this:

typedef GdkFilterReturn (*GdkFilterFunc) (GdkXEvent *xevent,
                                          GdkEvent *event,
                                          gpointer  data);

and GdkXEvent is defined as

typedef void GdkXEvent;   /* Can be cast to window system specific
                           * even type, XEvent on X11, MSG on Win32.
                           */

But Wayland doesn't have any struct types for events; instead, the client registers handlers for the various events, like

         void (*enter)(void *data,
                      struct wl_pointer *wl_pointer,
                      uint32_t serial,
                      struct wl_surface *surface,
                      wl_fixed_t surface_x,
                      wl_fixed_t surface_y);

We could certainly define structs ourselves, like

typedef struct GdkWEventEnter {
                      gint type;
                      void *data;
                      struct wl_pointer *wl_pointer;
                      uint32_t serial;
                      struct wl_surface *surface;
                      wl_fixed_t surface_x;
                      wl_fixed_t surface_y;
}

and then

union GdkWEvent {
  GdkWEventEnter enter;
  GdkWEventLeave leave;
  ...
}

On the other hand, the common use for filter function is to deal with root window properties and client messages - both things that don't exist under Wayland.

I use it to catch motion events on every window in my app without having to deal with specific widgets eating the events without me seeing them.

The win32 backend just passes NULL for the native event struct.

passing NULL misses the point entirely...

(In reply to comment #3)
> I use it to catch motion events on every window in my app without having to
> deal with specific widgets eating the events without me seeing them.

To do this you'd need to write some wayland specific code in totem to do this: basically you'd need to create a proxy for the seat (by looking for the global) and then setup a listener on that proxy.

This would be quite a bit of work I admit - but i'm not sure how we could use the existing mechanism to help you solve this problem with wayland.

Bastien, I don't think we should go with the approach of adding these structures. It really feels like it goes against the Wayland architecture.

I'm happy to help you with setting up the pointer listener using libwayland-client to catch these events.