[PATCH 18/36] privates: when pixmap privates increase, bump the totalPixmapSize

[Dave Airlie]

On Tue, Jul 3, 2012 at 12:41 AM, Keith Packard <keithp at keithp.com> wrote:
> Adam Jackson <ajax at nwnk.net> writes:
>
>> On 7/2/12 6:13 AM, Dave Airlie wrote:
>>> From: Dave Airlie <airlied at redhat.com>
>>>
>>> This bumps totalPixmapSize in all attached screens.
>>
>> Aieee.  totalPixmapSize is now monotonically increasing every time you
>> plug something in.  Until it wraps, of course, and then bang.  Not sure
>> what a better solution looks like, but IWBNI host storage was shared if
>> possible.
>
> Ok, so how about we fix the privates stuff so that drivers can allocate
> per-screen private data by sticking a DevPrivateKeyRec inside their
> screen private structure? And then we make it so you can allocate
> per-screen private data after the server starts, but not other kinds?
>
> I think that'll be pretty straightforward, shouldn't cause performance
> regressions in drivers as they generally have a pointer to their screen
> private where they're currently using privates.
>
> With that, changing clients to use the serverClient mechanism for
> privates (a pointer instead of a directly allocated chunk), and also
> using that same scheme for glyphs and we should be able to make this work.
>

Let me start by saying "fucking privates".

So I'm not sure what you mean by per-screen private data, drivers have
requirements for per-pixmap private data as well, currently by modesetting
driver stashes the slave framebuffer id from the kernel into a pixmap private.

Hence why I have to adjust the total pixmap size, though as ajax pointed
out its a bit monotonically increasing for sanity, I'll have to track
down it and see.

Dave.