[rcore][drm] Replace DRM swap buffer implementation with asynchronous page-flipping and triple framebuffer caching

[rob-bits]

The original implementation created/destroyed framebuffers (FBs) per-frame, leading to kernel overhead and screen tearing. This commit replaces it with a different approach using:

• Asynchronous drmModePageFlip() with vblank sync
• Framebuffer caching to reduce repeated FB creation/removal operations
• Proper resource management through BO callbacks and buffer release synchronization
• Added error handling for busy displays, cache overflows, and flip failures
• Event-driven cleanup via page_flip_handler to prevent GPU/scanout conflicts

Would you please review this code?
In my case it works better, has less framedrop or tearing.
Tested it on a Raspberry Pi Zero 2W.

Maybe this implementation should be handled as a compiler option for the user. To select if he wants the minimal DRM or the page-flipping, cached DRM.

Summary: Key Differences

Aspect	Function (SwapScreenBuffer - Original)	Function (SwapScreenBuffer new)
Framebuffer Creation	Creates/removes an FB per frame (expensive).	Caches Fbs for reuse; minimizes kernel operations.
Flip Synchronization	No vblank sync: likely causes tearing.	Uses drmModePageFlip() with vblank sync to prevent tearing.
Error Handling	Minimal recovery (logs errors, continues).	Graceful error handling and tracking via counters/callbacks.
Resource Management	Frees buffers immediately; risks conflicts.	Properly releases BOs/Fbs only after flips complete.
Complexity/Overhead	Simple code but performs poorly at high frame rates.	More complex but optimizes for performance

---

[raysan5]

Yes, that's correct, it was increased to address some z-fighting isssues. Afaik, most devies already support 24bit depth buffers.

[raysan5]

@rob-bits Thanks for the improvement, it would be nie to keep both methods to be selected with a compilation flag.

Please, could you first review the code to follow raylib coding conventions?

[rob-bits]

@rob-bits Thanks for the improvement, it would be nie to keep both methods to be selected with a compilation flag.

Please, could you first review the code to follow raylib coding conventions?

Yeah, will review it and revisit the code if it brokes any convention. And will add a compiler define to have control which one should be used.

[rob-bits]

Added compilation config flag and reimplemented some variable names to be compatible with coding conventions. The default code points to the original implementation. With additional testing, benchmarking later we can move on with this.