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

Dave Airlie airlied at gmail.com
Tue Jul 3 05:05:19 PDT 2012

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.


More information about the xorg-devel mailing list