Lightening the screen proc wrapping jungle

[Enrico Weigelt, metux IT consult]

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
info at metux.net -- +49-151-27565287