On Die, 2013-04-16 at 11:42 -0600, Daniel Drake wrote: > On Tue, Apr 16, 2013 at 11:22 AM, Michel Dänzer <[email protected]> wrote: > > On Die, 2013-04-16 at 10:54 -0600, Daniel Drake wrote: > >> On Sat, Apr 13, 2013 at 11:14 AM, Chris Wilson <[email protected]> > >> wrote: > >> > Given the same fix works, it does sound like a very similar issue. The > >> > difference is that the DDX is under control of the creating the scratch > >> > pixmap in your case and should be well aware of the lifetime constraints > >> > and so remember to decouple the GPU object when it destroys the screen > >> > pixmap. So the bug is really in the driver and this just happens to > >> > workaround the bug by forcing the release > >> > >> Good that you have a feeling for where the real problem actually is. > >> I'm happy to fix the driver, but I am facing a bit of a learning > >> curve. If I get a good grasp on things, I will try to produce some > >> documentation for the next person... > >> > >> So, the DDX is in control of pixmap allocations. It does that by > >> providing these hooks: > >> > >> if (pExa->flags & EXA_HANDLES_PIXMAPS) > >> { > >> pExa->CreatePixmap = NULL; > >> pExa->CreatePixmap2 = mrvlExaCreatePixmap2; > >> pExa->DestroyPixmap = mrvlDestroyPixmap; > >> pExa->ModifyPixmapHeader = mrvlModifyPixmapHeader; > >> pExa->PixmapIsOffscreen = mrvlPixmapIsOffscreen; > >> } > > > > Do you really need the ModifyPixmapHeader hook? It shouldn't be > > necessary with CreatePixmap2. Do things work better without it? > > Causes a crash early in X init. Maybe this has uncovered a driver bug?
Possibly. E.g. I see that mrvlPrepareAccess() returns TRUE but doesn't set pPix->devPrivate.ptr. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
