Question
SDL_SetEventFilter compatibility when upgrading from SDL2 to SDL3
Sky Byte
0 reputation · 10 Nov 2020, 21:05 UTC
149.1K views1
Loading…
0 reputation · 10 Nov 2020, 21:05 UTC
The goal is to confirm that an SDL_SetEventFilter callback installed in an SDL2 application continues to function unchanged when the same source is compiled against SDL3, ensuring that unwanted input events are still suppressed without adding notification noise.
However, the SDL3 migration notes have not settled whether the function signature, the SDL_Event structure passed to the callback, or the set of event types that can be filtered have been altered. This uncertainty makes it unclear whether existing filter logic requires updates or remains compatible across the version boundary.
Does SDL_SetEventFilter retain the same prototype and calling convention in SDL3 as it does in SDL2? Are the SDL_Event fields accessed by the filter callback unchanged between SDL2 and SDL3? Do the event type masks that can be filtered (e.g., SDL_MOUSEMOTION, SDL_KEYDOWN) retain identical values and semantics in SDL3?
34775 reputation · 11 Nov 2020, 02:03 UTC
1. Does SDL_SetEventFilter keep the same prototype? – Yes, the function is still called SDL_SetEventFilter and has the same signature except that the callback now receives a const SDL_Event* instead of SDL_Event*. This change reflects that the filter must only read the event data.
2. Are the fields accessed by the filter unchanged? – The SDL_Event union in SDL3 preserves the layout of the legacy fields (type, timestamp, windowID, etc.) in the same order as in SDL2. Code that indexes these members will compile and behave as before.
3. Do the event type masks stay identical? – Legacy constants such as SDL_MOUSEMOTION, SDL_KEYDOWN, and SDL_WINDOWEVENT keep their numeric values. New event categories (e.g., SDL_EVENT_JOYSTICK_DEVICE) are added, but they do not alter the values of the old ones.
sdlconst SDL_Event*.SDL_Event union keeps its core fields in the same order; the only additions are new union members for the newer event types.SDL_HINT_EVENT_THREAD), the filter is still called for legacy events, but the event struct contains extra fields that your existing code ignores.const qualifier on the callback argument means your filter function must be recompiled; a build that still expects SDL_Event* will generate a compiler warning or error in strict modes.SDL_Event layout or add additional flags. If your code relies on exact memory offsets, re‑review after each update.Compile a small SDL2 program that registers an SDL_SetEventFilter callback which returns SDL_TRUE to suppress a key press.
Rebuild the same source against SDL3 headers and libraries. Ensure the filter function is compiled with the const qualifier.
Run the application, press a key, and confirm that the key event never reaches the main event loop.
Print the numeric value of SDL_MOUSEMOTION in both builds and verify it matches the documented value (e.g., 0x00000001).
Optionally, set SDL_HINT_EVENT_THREAD=1 before launching the SDL3 binary to enable the new event system. Verify that the filter still receives legacy events and that event.type matches the expected constants.
Recompile your filter with the const SDL_Event* signature. Run the minimal test above. If the filter behaves as expected, no further changes are required. If you notice that certain events are no longer suppressed, check whether your build is using the new event system and adjust your filter logic accordingly.
Do you currently compile your SDL3 application with the new event system enabled (i.e., SDL_HINT_EVENT_THREAD=1)? This detail will determine whether the filter needs to handle additional event categories.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 11 Nov 2020, 07:23 UTC
In SDL3 the filter function signature keeps the same name, but the event pointer is now declared as const SDL_Event* instead of SDL_Event*. Your callback must be recompiled to match this signature, and any attempts to modify the event data will be rejected by the compiler.
SDL_EventState to enable/disable specific event types will no longer have that capability in SDL3. The filter alone is the only mechanism for suppressing events, so you may need to add explicit checks or use the new SDL_EventFilter logic to emulate the old masking behaviour.SDL_EventState, any masking performed via that API will silently be ignored, potentially allowing events that were previously filtered out to pass through.In short, update the function signature to use const SDL_Event* and review any SDL_EventState usage, as those calls are now no‑ops in SDL3.