On Mon, Jul 2, 2012 at 10:10 PM, Adam Jackson <[email protected]> wrote: > On 7/2/12 6:13 AM, Dave Airlie wrote: >> >> From: Dave Airlie <[email protected]> >> >> These asserts stop us increasing the size of privates after create screen >> resources has been called, however for dynamic screens we need to be able >> to increase private size as new drivers are loaded. >> >> In theory any object allocated by an older driver won't try and use newer >> privates and any object allocated by a new driver should be okay. > > > I... don't know if I believe this. What objects did you find that had this > property? >
When I say older/newer driver I mean, loaded at startup, secondary loaded drivers btw. So far the modesetting driver is the only thing to exercise this, for its offload stuff it needs a pixmap private allocated, so I hit this problem and the subsequent one. Now if we allocate 20 pixmaps before the second driver is loaded, they'll look like PixmapHeader + privates + pixmap data. the privates will have been handed out to the current list of keys register on PRIVATE_PIXMAP. Now we bump the size, and we allocate pixmap 21, PixmapHeader + privates + newpriv + pixmap data. Now the new driver will never get to see pixmaps 1->20 since there is no way it should ever see pixmaps allocated on the other drivers, and pixmap 21 and future pixmap will work fine. If driver 2 unloads the pixmaps 21 etc should all be destroyed, and in that case we probably should decrease the total pixmap size again. but privates have always longed remained something I run away screaming from everytime I see them. Dave. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
