[RFC] Xorg symbols that should not be public
Peter Hutterer
peter.hutterer at who-t.net
Thu Dec 11 00:35:49 PST 2008
On Tue, Dec 09, 2008 at 12:36:01AM -0200, Paulo César Pereira de Andrade wrote:
> In my Linux x86 computer, using only git master, and with X Server
> configured with "--prefix=/usr --disable-builtin-fonts --enable-dri2
> --enable-dri --enable-xephyr"
>
> With all buildable modules also installed, attached is the list
> of symbols that are not used by any module.
>
> There are 2 main kinds of symbols that should be public:
> o Symbols accessed by input/video modules
> o Symbols accessed by extensions or other kind of modules
>
> And of course, there is a large amount of symbols in the list
> that should not be exported. And some should have a stub when
> some feature is disabled.
>
> I think some private headers, for things like libextmod, libxaa,
> libfb, etc, should be created, still with symbols exported at
> first, to guarantee binary compatibility. But some symbols that
> are currently exported should be made private, and not advertised
> in the sdk, as they are only used in the X Server binary.
I went through the list, see comments below. I'm sure I missed symbols, and I
left a few where I'm not sure. One thing that worries me is that several were
listed that are clearly part of the driver API. We need to be very careful
reducing the number of exported symbols so that we don't cut down APIs that
are useful and may be needed in the near future.
> F ActivateDevice
> F ActivateKeyboardGrab
> F ActivatePointerGrab
> F AllowSome
I can see those getting used by extensions in the future.
> F AddOtherInputDevices
deprecated anyway, AFAICT
> F AllocMasterDevice
Maybe needed by extensions (XInput for example, but that one is built in
anyway)
> F DefineInitialRootWindow
Deprecated, should prob be removed.
> F NewInputDeviceRequest
> F DeleteInputDeviceRequest
Must be exported, needed by linuxwacom.
> F DeliverEventsToWindow
Might be needed needed by extensions.
> F EnableDevice
> F DisableDevice
Not needed, may be needed in the
> F GetKeyboardEvents
> F GetKeyboardValuatorEvents
> F GetMaximumEventsNum
> F GetMotionHistory
> F GetPointerEvents
> F GetProximityEvents
> F GetSpriteCursor
> F GetSpritePosition
> F GetSpriteWindow
> F InitEventList
All these may be needed by extensions.
> F InitAbsoluteClassDeviceStruct
> F InitIntegerFeedbackClassDeviceStruct
> F InitKbdFeedbackClassDeviceStruct
> F InitPointerAccelerationScheme
Part of the input driver API.
> F InitAndStartDevices
This one is internal only.
> F InitInput
> F InitOutput
Part of DDX API for the DIX.
> F mieqEnqueue
This is the central event enqueuing API. Hiding this means no extension or
driver can sneak events into the EQ.
> F PickKeyboard
> F PickPointer
Needed by extensions.
> F ProcAllowEvents
> F ProcBadRequest
> F ProcChangeActivePointerGrab
all Proc* are request processing, should be internal only.
> F SAllocColorCellsReply
All SWhateverReply and SWhateverEvent are byte-swapping functions, should be
internal only.
> F SendEventToAllWindows
Needed by extensions.
> F SProcAllocColor
SProcWhatever is for byte-swapping, should be internal only.
> F xf86addNewOption
> F xf86NewOption
> F xf86nextOption
> F xf86NextOption
Leave exported, may be needed by drivers.
> F xf86CheckIfOptionUsed
> F xf86CheckIfOptionUsedByName
> F xf86CheckIntOption
> F xf86CheckRealOption
> F xf86ReplaceRealOption
Part of the driver API, I think the second one is currently used by synaptics
(or by one of the patches in my queue).
> F XIDeleteDeviceProperty
> F XIGetDeviceProperty
> F XIGetKnownProperty
> F XIUnregisterPropertyHandler
Part of the propety API, leave exported.
> O CoreDevicePrivateKey
Internal only, i think this one is even removed in daniel's xkb-atkins branch.
> O noDamageExtension
> O noMITShmExtension
> O noRenderExtension
> O noRRExtension
> O noTestExtensions
> O noXFixesExtension
All these are standard to test whether an extension is enabled/disabled. Leave
them.
> O ProcGEVector
Internal only.
> O ProcRandrVector
> O ProcVector
Pretty sure these are internal only too.
Cheers,
Peter
More information about the xorg
mailing list