> Date: Wed, 16 May 2012 10:16:24 +0100 > From: Dave Airlie <[email protected]> > > > > >> @@ -340,7 +341,7 @@ vbeDoEDID(vbeInfoPtr pVbe, pointer pDDCModule) > >> if (!DDC_data) > >> return NULL; > >> > >> - pMonitor = xf86InterpretEDID(pVbe->pInt10->scrnIndex, DDC_data); > >> + pMonitor = xf86InterpretEDID(pVbe->pInt10->pScrn->scrnIndex, > >> DDC_data); > > > > > > The callee here wants index->ptr conversion too, doesn't it? I don't think > > I see that in subsequent patches. > > That gets into an area I've been thinking about but mostly avoiding for now, > > That is pretty much a logging function, i.e. scrnIndex only goes into > logging functions, > > Now I'm tempted to leave logging functions just passing indices, but > I'm thinking its probably a bad idea long term, just not sure what it > is short-term. > > I was thinking of just making scrnIndex for GPU screens have a > higher-bit set in them, and the logging would understand that and > strip it out, or maybe creating a new logging index that gets passed > to all the logging functions. > > However I was playing with using a combo or scrnIndex and isGPU to > denote a GPU screen, and it seems cleaner, but the big problem is > changing the logging function signatures is a major amount of work, > the API changes I've been making are moderate in comparison, but > everyone calls the logging functions from some really wierd places so > there would be a lot of audit. > > So I think thinking short-term, I just do the high-bit or start gpu > screens after MAXSCREENS, and make sure to never expose that > implementation detail to drivers, then once we are past the worst of > this we can contemplate some way to fix the logging interfaces.
How about adding an interface that converts a screen pointer into a string of some sorts and use that in the logging functions?
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
