On Fri, 30 Dec 2011 15:26:10 -0400
Anderson Lizardo <anderson.lizardo@xxxxxxxxxxxxx> wrote:
> "sixpair" is a standalone tool to manage PS3 controllers. It was the
> only tool not being built by default.
>
> To build it, it is necessary to check for libusb-1.0 (besides the
> existing libusb 0.1 check). The check is optional, and sixpair will not
> be built if libusb-1.0 headers are not installed.
> ---
>
> I personally never used this tool. So I'm not sure if the best approach is to
> completely remove it instead. If that's the case, let me know so I send a patch
> removing the .c file instead.
>
Hi Anderson,
I'd say the .c file can be removed if you want to, when I have time I am
going to resend the playstation-peripheral plugin and the prerequisite
patches to have it as an _external_ plugin, I hope to do that next
week.
In my previous submissions of the playstation-peripheral plugin I was
removing this .c file just before adding the new plugin, and I am going
to "revert" this patch anyways, so you can choose to drop this patch
and let me remove the .c file when I add the plugin, or remove it right
now. I think there isn't much of a gain enabling the build of the
sixpair.c currently in BlueZ.
I am adding Bastien on CC as he was the author of the sixpair currently
in BlueZ, Bastien what do you think?
Thanks,
Antonio
> .gitignore | 1 +
> Makefile.tools | 10 ++++++++++
> acinclude.m4 | 5 +++++
> 3 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index badd1a0..0c5ef15 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -46,6 +46,7 @@ sbc/sbcinfo
> sbc/sbctester
>
> attrib/gatttool
> +input/sixpair
> tracer/hcitrace
> tools/avctrl
> tools/avinfo
> diff --git a/Makefile.tools b/Makefile.tools
> index eea1a9b..400ed1b 100644
> --- a/Makefile.tools
> +++ b/Makefile.tools
> @@ -63,6 +63,16 @@ attrib_gatttool_SOURCES = attrib/gatttool.c attrib/att.c attrib/gatt.c \
> attrib_gatttool_LDADD = lib/libbluetooth-private.la @GLIB_LIBS@ @READLINE_LIBS@
> endif
>
> +if SIXPAIR
> +noinst_PROGRAMS += input/sixpair
> +
> +input_sixpair_CFLAGS = $(AM_CFLAGS) @USB10_CFLAGS@
> +input_sixpair_SOURCES = input/sixpair.c src/storage.c src/storage.h \
> + src/textfile.c src/textfile.h src/glib-helper.c \
> + src/glib-helper.h
> +input_sixpair_LDADD = lib/libbluetooth-private.la @GLIB_LIBS@ @USB10_LIBS@
> +endif
> +
> dist_man_MANS += tools/rfcomm.1 tools/l2ping.8 \
> tools/hciattach.8 tools/hciconfig.8 \
> tools/hcitool.1 tools/sdptool.1 tools/ciptool.1
> diff --git a/acinclude.m4 b/acinclude.m4
> index 4c72fee..f2a4845 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -141,6 +141,10 @@ AC_DEFUN([AC_PATH_USB], [
> AC_CHECK_LIB(usb, usb_interrupt_read, dummy=yes,
> AC_DEFINE(NEED_USB_INTERRUPT_READ, 1,
> [Define to 1 if you need the usb_interrupt_read() function.]))
> +
> + PKG_CHECK_MODULES(USB10, libusb-1.0, usb10_found=yes, usb10_found=no)
> + AC_SUBST(USB10_CFLAGS)
> + AC_SUBST(USB10_LIBS)
> ])
>
> AC_DEFUN([AC_PATH_UDEV], [
> @@ -427,6 +431,7 @@ AC_DEFUN([AC_ARG_BLUEZ], [
> AM_CONDITIONAL(PCMCIA, test "${pcmcia_enable}" = "yes")
> AM_CONDITIONAL(HID2HCI, test "${hid2hci_enable}" = "yes" && test "${usb_found}" = "yes" && test "${udev_found}" = "yes")
> AM_CONDITIONAL(DFUTOOL, test "${dfutool_enable}" = "yes" && test "${usb_found}" = "yes")
> + AM_CONDITIONAL(SIXPAIR, test "${usb10_found}" = "yes")
> AM_CONDITIONAL(DATAFILES, test "${datafiles_enable}" = "yes")
> AM_CONDITIONAL(MAEMO6PLUGIN, test "${maemo6_enable}" = "yes")
> AM_CONDITIONAL(DBUSOOBPLUGIN, test "${dbusoob_enable}" = "yes")
> --
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
Attachment:
pgpDLG7FKuKwl.pgp
Description: PGP signature
