Hello friends,
I'd like to to know that I'm currently in process of cleaning up the jungle of wrapping ScreenRec proc vectors, so we'll get clean and easy to understand code pathes. Some explaination for those who aren't deeply in this matter: 1. What is wrapping ? The Screen object (ScreenRec) has a bunch of call vectors that are usually filled by the DDX (*1) - in case of xfree86, often also by individual drivers. These are called by DIX (*2) in various situations, eg. init/teardown, when windows are created, moved, destroyed, etc, etc. The rationale is that there're device dependent things to do here (eg. an DDX based on another window system have to create/configure the underlying native windows, on certain HW one wants to allocate framebuffer space for a window, etc, etc). But now we have two aspects making it more complex: a) layered subsystems - eg. generic functions of the MI(*3) layer, which can take a lot of load from the DDX's shoulders, but sometimes the DDX (or driver) needs to intervene here. b) pluggable extensions - eg. DBE needs to intervene some procs in order no manage the buffers. 2. How is it one now ? Many places (not only extensions, sometimes even the DDX) intercepting certain procs by saving the old vector into an internal structure and putting their own one in here. On each call, the intercepting proc is temporarily restoring the old vector, calling it and then putting itself back in here. It's a bit of SW equivalent to a daisy chain. While this approach looks simple and elegant on the drawing board, it's very problematic in practise: It's very complex and hard to understand what's really going on here. Who had been wrapping whom ? What's the actual call chain. Setup and teardown *must* happen in the exact order, and there's no practical way to change things at runtime (eg. enable/disable affected extensions needs full server restart). That's making maintenance or even adding new extensions unnecessarily hard. How I'm gonna solve it: There two cases: a) the systems (eg. fb, mi, ...) and b) extensions Case a) replacing the wrapping by direct calls: eg. fb-based DDX doesn't wrap fb's procs, but calls them directly. Example: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1705 Case b) decoupling the individual procs from specific call orders and adding callback lists to the ScreenRec: extensions now can install (and remove) their calbacks independently from each other, and they're also called independently. example WIP branch: https://gitlab.freedesktop.org/metux/xserver/-/commits/wip/screenproc As usual, I'm trying to split long queues into separate disjunct ones, so expect several MRs related to that topic. --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
