> >> @@ -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. 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