[RFC] xserver: rip indexes out of the API/ABI

Aaron Plattner aplattner at nvidia.com
Wed Apr 25 17:10:57 PDT 2012


On 04/10/2012 02:10 PM, Alan Coopersmith wrote:
> On 04/10/12 07:47 AM, Dave Airlie wrote:
>> This patch series tears strips out of the current API, its not complete,
>> with further changes to ddc/i2c code I can remove all references to
>> xf86Screens from drivers. I've got a bit more work to stop them
>> peaking inside screenInfo.
>
> And of course I went through them all before noticing it was just an RFC,
> not a full review - that said, I'm pretty okay with them, other than the
> handful of docs notes and the couple of questions I asked about consistency.

I just skimmed all the changes, and they don't look particularly 
horrible.  It'll require some #ifdeffery on my part, but I can live with 
that.

However, actually removing screenInfo.screens and screenInfo.numScreens 
is going to get tricky because there are a bunch of cases where we have 
to either compare screen numbers in protocol against numScreens and then 
look up a pScreen from there, or where we have to loop over all screens. 
  A dixForAllScreens / xf86ForAllScrnInfos iterator would solve the 
latter, but I don't know what the right plan is for the former.

I'm going to suppress the urge to complain about API cleanups that cause 
me to have to add #ifdefs to our code and try to look at this 
objectively.  :)  From an API cleanup standpoint, I think this is a good 
step.

>> Again it bears repeating , this tears up the current API pretty well,
>> I've ported -ati, and its not brutally ugly on the driver side, esp
>> if drivers define xf86ScrnToScreen and xf86ScreenToScrn themselves
>> when its not there.
>
> And one obvious gap is that the ABI version isn't bumped yet in this series,
> but really, someone like Aaron should look over it before that happens.

Yeah, I'll request an ABI bump when it's necessary.  I have to admit, 
I'm behind on reviewing X stuff so I don't know whether an ABI bump is 
already required in master or not.

-- Aaron


More information about the xorg-devel mailing list