[PATCH 15/19] xfree86: don't export xf86InputDevs.
Fernando Carrijo
fcarrijo.lists at gmail.com
Tue Sep 7 19:37:33 PDT 2010
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?
>
> /* xf86Xinput.c */
> extern _X_EXPORT void xf86PostMotionEvent(DeviceIntPtr device, int is_absolute,
> --
> 1.7.2.2
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
More information about the xorg-devel
mailing list