This is a draft PR with a fix for issues #685, #1911 and #2600 which works by only returning from the wait if either a GLFW relevant event is encountered or the timeout is reached if set.

Current status of backends

• Win32: implemented, tested as working as before but currently I do not have a repro of Wayland glfwWaitEvents() not waiting #1911
• Wayland: implemented and tested as resolving an issue with the same characteristics as glfwWaitEvents not waiting #685 by @memononen encountered on Fedora KDE.
• X11: implemented and tested as working as before
• Cocoa: not yet implemented

I do not have a Mac machine at the moment as mine has died, but I will see about using an online remote desktop service to implement the Cocoa branch if this PR architecture is deemed suitable.

Design

This PR adds a boolean newEventsRcvd to the _glfw global struct. This is set to GLFW_FALSE at the start of a poll/wait event call, and set to GLFW_TRUE if a GLFW relevant event is received, including one from a glfwPostEmptyEvent. The majority of the code for newEventsRcvd state management is in cross platform code.

Each platform adds a loop to the 2 wait event calls, reducing the timeout by the passage of time where required (note to self: POSIX implementation may need timeout adjustment). This code could potentially be moved to the cross platform code.

Each platform needs to handle the glfwPostEmptyEvent on the same thread as the glfwWaitEvents* call (the main thread by design).

• Wayland adds a handler for the wl_display_sync display sync done
• X11 adds code to the drainEmptyEvents pipe function
• Win32 adds a WM_NULL case to the helper window procedure
• Cocoa will need to handle the NSApplicationDefined NSEvent for this.

Questions

1. Should we add an init hint to control this feature, and if so should it default to ON or OFF?
2. Is a boolean a reasonable choice, or should we move to a uint32_t or uint64_t event counter?
   2a. Should this be a global event counter or reset every event loop?
   2b. With atomics it might actually be possible to move the entire implementation to cross platform code. Whilst C99 does not have atomic integers I am well versed in their cross platform implementation and can add these if needed.
3. Do we expose this to applications, so they can know if the timeout was reached, or an event was encountered (or how many events if we move to a counter)?
4. Have I implemented all event types?

TODO

See Contributing a bug fix documentation for general requirements for a bug fix contribution, and if we add functions to control/query this then also the feature list.

• Cocoa implementation
• Answer questions above
• Add changelog entry
• If we extend the API then we need news page entry, documentation, reference documentation etc. as per the guide.