[PATCH 15/19] xfree86: don't export xf86InputDevs.

[Fernando Carrijo]

Peter Hutterer <peter.hutterer at who-t.net> wrote:

> On Tue, Sep 07, 2010 at 11:37:33PM -0300, Fernando Carrijo wrote:
> > Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > 
> > > Use xf86FirstLocalDevice() instead (but don't get me started on the naming
> > > of that one...)
> > 
> > Yeah, a poorly chosen name indeed.
> > 
> > > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > 
> > Reviewed-by: Fernando Carrijo <fcarrijo at freedesktop.org>
> > 
> > > ---
> > >  hw/xfree86/common/xf86Xinput.h |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/hw/xfree86/common/xf86Xinput.h b/hw/xfree86/common/xf86Xinput.h
> > > index 45bf573..7d0c44e 100644
> > > --- a/hw/xfree86/common/xf86Xinput.h
> > > +++ b/hw/xfree86/common/xf86Xinput.h
> > > @@ -122,7 +122,7 @@ struct _InputInfoRec {
> > >  typedef InputInfoRec *InputInfoPtr;
> > >  
> > >  /* xf86Globals.c */
> > > -extern _X_EXPORT InputInfoPtr xf86InputDevs;
> > > +extern InputInfoPtr xf86InputDevs;
> > 
> > Out of personal interest: I still don't understand how closed-source drivers
> > should deal with modifications like this. Initially I thought that exporting
> > a symbol represented a contract the server could never decline, but it seems
> > things do not work this way.
> >
> > The above change can be considered an API break? And are drivers supposed to
> > check for the server version before they assume xf86InputDevs can be directly
> > accessed?
> 
> The server has two APIs. One is the X protocol and its extension and these
> are indeed set in stone. toolkits, clients, etc. rely on it and we don't
> break it (or try not to in most cases anyway).
> 
> the other API is the video and input driver API. we have ABI_XINPUT_MAJOR
> and it is bumped each time we introduce incompatible changes for input
> drivers.. throughout a server release it stays the same so that drivers will
> work with any e.g.  1.8.x version. between major releases of the server, all
> bets are off. This commit is part of a series and one of the first in this
> series bumps the ABI to 12, so drivers can indeed adjust to these new calls.

I got the picture.

The header xf86Module.h defines macros like ABI_XINPUT_VERSION, which are
processed at build time by configure.ac:extract_abi(), and made available
to xorg-server.pc via AC_SUBST([abi_xinput]).

Wish I knew the autotools since the day I first read the X server code.

> in this particular commit: xf86FirstLocalDevice() has been around for ages
> too, so drivers could just switch to that and still be backwards-compatible
> without ifdef-ery.
> 
> closed-source drivers are someone else's problem, not mine :)
> 
> Cheers,
>   Peter