[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