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

[Peter Hutterer]

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.

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