Screen-specific private allocations

[Keith Packard]

The first patch extends the existing private allocation mechanism to
provide 'screen-specific' privates. These work almost exactly like
global privates, but space for them is allocated only in objects
associated with a single screen. In other words, a Window allocated on
screen 0 will not have space allocated for screen-specific privates
registered on screen 1.

Obviously this will save memory in servers with multiple
screens. However, more importantly this week, it will allow privates
to be allocated for hot-plug screens -- if those privates are all
screen-specific, then we can ensure that all objects associated with
the new screen are correctly initialized.

The second patch shows how this works in the 'fb' layer, the third
does the same for 'exa'.

I've tested the 'fb' patch by running Xephyr, but I have not tested
the third patch at all. It "should" work, but I don't have any
hardware that uses exa available to me.

Note that there is no requirement that existing code use these APIs,
as long as that code doesn't want to register private storage during
hotplug.

For private users, the only change is in where the keys are stored,
and how they are registered.

Because the keys are now screen-specific, they'll want to be stored in
the screen private structure for the associated module. That way,
different screens can have the private storage at different offsets,
depending on what other modules are using that screen.

And, of course, registering the new key requires a screen parameter so
that the server knows which objects need the storage.

extern _X_EXPORT Bool
dixRegisterScreenSpecificPrivateKey(ScreenPtr pScreen, DevPrivateKey key,
                                    DevPrivateType type, unsigned size);

You'll note that the server already offers something called
'ScreenPrivates' these are just about the exact opposite of the new
screen-specific privates. 'ScreenPrivate's provide storage in a
non-screen-specific structure for data associated with a specific
screen. These were created to hold screen-specific information about a
cursor for the midispcur layer. I can't think of how a driver would
ever use them.

Right now, the objects which support screen-specific privates are
Windows, Pixmaps, GCs and Pictures. Adding Colormaps would be
reasonably straightforward if there's a need.