On Tue, Jul 3, 2012 at 12:41 AM, Keith Packard <kei...@keithp.com> wrote: > Adam Jackson <a...@nwnk.net> writes: > >> On 7/2/12 6:13 AM, Dave Airlie wrote: >>> From: Dave Airlie <airl...@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. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel