hidapi: new package

PATCH New Vicente Olivert Riera 4 participants 9 messages Nov 16, 2015 – Nov 26, 2015

lore

Share & tools

lore

Vicente Olivert Riera

author

2015-11-16 16:54 UTC #0 lore raw

PATCH 1/1 hidapi: new package

Signed-off-by Vicente Olivert Riera <[email protected]>

---
 package/Config.in          |    1 +
 package/hidapi/Config.in   |   20 ++++++++++++++++++++
 package/hidapi/hidapi.hash |    2 ++
 package/hidapi/hidapi.mk   |   27 +++++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 0 deletions(-)
 create mode 100644 package/hidapi/Config.in
 create mode 100644 package/hidapi/hidapi.hash
 create mode 100644 package/hidapi/hidapi.mk

package/Config.in +1 -0

index bdc3063..04800c5 100644
@@ -864,6 +864,7 @@ menu "Hardware handling"
 	source "package/ccid/Config.in"
 	source "package/dtc/Config.in"
 	source "package/gnu-efi/Config.in"
+	source "package/hidapi/Config.in"
 	source "package/lcdapi/Config.in"
 	source "package/libaio/Config.in"
 	source "package/libatasmart/Config.in"

package/hidapi/Config.in new file +20 -0

new file mode 100644
index 0000000..7fbc1c2
@@ -0,0 +1,20 @@
+config BR2_PACKAGE_HIDAPI
+	bool "hidapi"
+	depends on BR2_PACKAGE_HAS_UDEV
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libusb
+	select BR2_PACKAGE_LIBUSB
+	# When eudev is used as the udev provider, libgudev is
+	# automatically provided as it is part of eudev. However, when
+	# systemd is used as the udev provider, libgudev is not
+	# provided, and needs to be built separately. This is why we
+	# select the libgudev package only if systemd is used.
+	select BR2_PACKAGE_LIBGUDEV if BR2_PACKAGE_SYSTEMD
+	help
+	  HIDAPI is a multi-platform library which allows an application
+	  to interface with USB and Bluetooth HID-Class devices on
+	  Windows, Linux, and Mac OS X.
+
+	  http://www.signal11.us/oss/hidapi/
+
+comment "hidapi needs udev /dev management and a toolchain w/ threads"
+	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_HAS_UDEV

package/hidapi/hidapi.hash new file +2 -0

new file mode 100644
index 0000000..ba00df2
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 33e206f5e145fc1bc6aeb55084d71b55d686533d23ad5bb762746ceba81e728b  hidapi-d17db57b9d4354752e0af42f5f33007a42ef2906.tar.gz

package/hidapi/hidapi.mk new file +27 -0

new file mode 100644
index 0000000..23d5eab
@@ -0,0 +1,27 @@
+################################################################################
+#
+# hidapi
+#
+################################################################################
+
+# Use master version as the current stable is very old and some bugs
+# have been fixed since then.
+HIDAPI_VERSION = d17db57b9d4354752e0af42f5f33007a42ef2906
+HIDAPI_SITE = $(call github,signal11,hidapi,$(HIDAPI_VERSION))
+HIDAPI_INSTALL_STAGING = YES
+# No configure provided, so we need to autoreconf.
+HIDAPI_AUTORECONF = YES
+HIDAPI_LICENSE = GPLv3, BSD-3c
+HIDAPI_LICENSE_FILES = LICENSE.txt LICENSE-gpl3.txt LICENSE-bsd.txt
+
+HIDAPI_DEPENDENCIES = libusb
+# When eudev is used as the udev provider, libgudev is automatically
+# provided as it is part of eudev. However, when systemd is used as the
+# udev provider, libgudev is not provided, and needs to be built
+# separately. This is why we select the libgudev package only if systemd
+# is used.
+ifeq ($(BR2_PACKAGE_SYSTEMD),y)
+HIDAPI_DEPENDENCIES += libgudev
+endif
+
+$(eval $(autotools-package))

Signature · 1 line

1.7.1

Baruch Siach

2015-11-16 18:07 UTC #1 lore raw

PATCH 1/1 hidapi: new package

Hi Vincent,

Quoted 1 line · Vicente Olivert Riera

Signed-off-by Vicente Olivert Riera <[email protected]>

[...]

package/hidapi/hidapi.mk line 23

Quoted 7 lines

package/hidapi/hidapi.mk new file +7 -0

+HIDAPI_DEPENDENCIES = libusb
+# When eudev is used as the udev provider, libgudev is automatically
+# provided as it is part of eudev. However, when systemd is used as the
+# udev provider, libgudev is not provided, and needs to be built
+# separately. This is why we select the libgudev package only if systemd
+# is used.
+ifeq ($(BR2_PACKAGE_SYSTEMD),y)

Should be 'ifeq ($(BR2_PACKAGE_LIBGUDEV),y)', in think, since all we need is to have libgudev built before this package, regardless of systemd. With this change the comment becomes redundant. The comment in Config.in should be enough.

package/hidapi/hidapi.mk line 25

Quoted 2 lines

package/hidapi/hidapi.mk new file +2 -0
+HIDAPI_DEPENDENCIES += libgudev
+endif

baruch

Signature · 3 lines

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Vicente Olivert Riera

author

2015-11-17 10:11 UTC #2 lore raw

PATCH 1/1 hidapi: new package

Hello Baruch,

Quoted 7 lines · Baruch Siach

Hi Vincent,
Quoted 1 line · Vicente Olivert Riera
Signed-off-by Vicente Olivert Riera <[email protected]>
[...]

Quoted 12 lines

package/hidapi/hidapi.mk line 23
Quoted 7 lines
package/hidapi/hidapi.mk new file +7 -0
+HIDAPI_DEPENDENCIES = libusb
+# When eudev is used as the udev provider, libgudev is automatically
+# provided as it is part of eudev. However, when systemd is used as the
+# udev provider, libgudev is not provided, and needs to be built
+# separately. This is why we select the libgudev package only if systemd
+# is used.
+ifeq ($(BR2_PACKAGE_SYSTEMD),y)
Should be 'ifeq ($(BR2_PACKAGE_LIBGUDEV),y)', in think, since all we need is to have libgudev built before this package, regardless of systemd. With this change the comment becomes redundant. The comment in Config.in should be enough.

we need libgudev only if we are going to use systemd. Otherwise it will be provided by eudev.

Of course we could use ifeq ($(BR2_PACKAGE_LIBGUDEV),y) here, but, for consistency with Config.in, I use ifeq ($(BR2_PACKAGE_SYSTEMD),y) instead. See for instance the udisks package.

Regards,

Vincent.

Quoted 5 lines

package/hidapi/hidapi.mk line 25
Quoted 2 lines
package/hidapi/hidapi.mk new file +2 -0
+HIDAPI_DEPENDENCIES += libgudev
+endif
baruch

Baruch Siach

2015-11-18 04:50 UTC #3 lore raw

PATCH 1/1 hidapi: new package

Hi Vincent,

Quoted 19 lines · Vicente Olivert Riera

Quoted 5 lines · Baruch Siach
Quoted 1 line · Vicente Olivert Riera
Signed-off-by Vicente Olivert Riera <[email protected]>
[...]
Quoted 12 lines
package/hidapi/hidapi.mk line 23
Quoted 7 lines
package/hidapi/hidapi.mk new file +7 -0
+HIDAPI_DEPENDENCIES = libusb
+# When eudev is used as the udev provider, libgudev is automatically
+# provided as it is part of eudev. However, when systemd is used as the
+# udev provider, libgudev is not provided, and needs to be built
+# separately. This is why we select the libgudev package only if systemd
+# is used.
+ifeq ($(BR2_PACKAGE_SYSTEMD),y)
Should be 'ifeq ($(BR2_PACKAGE_LIBGUDEV),y)', in think, since all we need is to have libgudev built before this package, regardless of systemd. With this change the comment becomes redundant. The comment in Config.in should be enough.

Quoted 6 lines

we need libgudev only if we are going to use systemd. Otherwise it will be provided by eudev.
Of course we could use ifeq ($(BR2_PACKAGE_LIBGUDEV),y) here, but, for consistency with Config.in, I use ifeq ($(BR2_PACKAGE_SYSTEMD),y) instead. See for instance the udisks package.

I think this is wrong. First, consistency with Config.in calls for using BR2_PACKAGE_LIBGUDEV like we do with all other selects. But more importantly, IMO, we only use the <pkg>_DEPENDENCIES variable to set the build order which is conceptually independent of the underlying reason we need this dependency, systemd in this case. I think that all the other packages that Thomas mentioned should also test for BR2_PACKAGE_LIBGUDEV when setting <pkg>_DEPENDENCIES.

baruch

Signature · 3 lines

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Thomas Petazzoni

2015-11-18 08:22 UTC #4 lore raw

PATCH 1/1 hidapi: new package

Baruch,

Quoted 11 lines · Baruch Siach

Quoted 3 lines
Of course we could use ifeq ($(BR2_PACKAGE_LIBGUDEV),y) here, but, for consistency with Config.in, I use ifeq ($(BR2_PACKAGE_SYSTEMD),y) instead. See for instance the udisks package.
I think this is wrong. First, consistency with Config.in calls for using BR2_PACKAGE_LIBGUDEV like we do with all other selects. But more importantly, IMO, we only use the <pkg>_DEPENDENCIES variable to set the build order which is conceptually independent of the underlying reason we need this dependency, systemd in this case. I think that all the other packages that Thomas mentioned should also test for BR2_PACKAGE_LIBGUDEV when setting <pkg>_DEPENDENCIES.

I am not as clear-cut as you are on what is the correct thing to do here, but your reasoning seems reasonable to me. So we need to align the existing packages to do this, and also to use BR2_INIT_SYSTEMD in Config.in (udisks uses BR2_PACKAGE_SYSTEMD). Will you send some patches or should I do so?

Thanks,

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Baruch Siach

2015-11-18 08:45 UTC #5 lore raw

PATCH 1/1 hidapi: new package

Hi Thomas,

Quoted 13 lines · Thomas Petazzoni

Quoted 11 lines · Baruch Siach
Quoted 3 lines
Of course we could use ifeq ($(BR2_PACKAGE_LIBGUDEV),y) here, but, for consistency with Config.in, I use ifeq ($(BR2_PACKAGE_SYSTEMD),y) instead. See for instance the udisks package.
I think this is wrong. First, consistency with Config.in calls for using BR2_PACKAGE_LIBGUDEV like we do with all other selects. But more importantly, IMO, we only use the <pkg>_DEPENDENCIES variable to set the build order which is conceptually independent of the underlying reason we need this dependency, systemd in this case. I think that all the other packages that Thomas mentioned should also test for BR2_PACKAGE_LIBGUDEV when setting <pkg>_DEPENDENCIES.

Quoted 5 lines

I am not as clear-cut as you are on what is the correct thing to do here, but your reasoning seems reasonable to me. So we need to align the existing packages to do this, and also to use BR2_INIT_SYSTEMD in Config.in (udisks uses BR2_PACKAGE_SYSTEMD). Will you send some patches or should I do so?

I'll send the patches later. Would you like one patch per package, or a single patch based on next?

baruch

Signature · 3 lines

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Thomas Petazzoni

2015-11-18 08:55 UTC #6 lore raw

PATCH 1/1 hidapi: new package

Dear Baruch Siach,

Quoted 8 lines · Baruch Siach

Quoted 5 lines
I am not as clear-cut as you are on what is the correct thing to do here, but your reasoning seems reasonable to me. So we need to align the existing packages to do this, and also to use BR2_INIT_SYSTEMD in Config.in (udisks uses BR2_PACKAGE_SYSTEMD). Will you send some patches or should I do so?
I'll send the patches later. Would you like one patch per package, or a single patch based on next?

I think a single patch is good enough, the number of affected packages is pretty small.

Thanks,

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Thomas Petazzoni

Applied

2015-11-17 21:04 UTC #7 lore raw

PATCH 1/1 hidapi: new package

In reply to Vicente Olivert Riera

Dear Vicente Olivert Riera,

Quoted 10 lines · Vicente Olivert Riera

Signed-off-by Vicente Olivert Riera <[email protected]>

---
 package/Config.in          |    1 +
 package/hidapi/Config.in   |   20 ++++++++++++++++++++
 package/hidapi/hidapi.hash |    2 ++
 package/hidapi/hidapi.mk   |   27 +++++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 0 deletions(-)
 create mode 100644 package/hidapi/Config.in
 create mode 100644 package/hidapi/hidapi.hash
 create mode 100644 package/hidapi/hidapi.mk

Applied to next, with a few changes:

[Thomas:
- use BR2_INIT_SYSTEMD instead of BR2_PACKAGE_SYSTEMD for the libgudev handling. This is consistent with what we do in libmbim, modem-manager and network-manager. Only udisks is diverging from this by using BR2_PACKAGE_SYSTEMD.
- Fix the license info: it is GPLv3 *or* BSD-3c *or* the specific HIDAPI license. Added LICENSE-orig.txt to LICENSE_FILES.]

Thanks,

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Alan Ott

2015-11-26 04:14 UTC #8 lore raw

PATCH 1/1 hidapi: new package

In reply to Vicente Olivert Riera

Quoted 80 lines · Vicente Olivert Riera

Signed-off-by Vicente Olivert Riera <[email protected]>

---
  package/Config.in          |    1 +
  package/hidapi/Config.in   |   20 ++++++++++++++++++++
  package/hidapi/hidapi.hash |    2 ++
  package/hidapi/hidapi.mk   |   27 +++++++++++++++++++++++++++
  4 files changed, 50 insertions(+), 0 deletions(-)

create mode 100644 package/hidapi/Config.in
create mode 100644 package/hidapi/hidapi.hash
create mode 100644 package/hidapi/hidapi.mk

package/Config.in +1 -0

index bdc3063..04800c5 100644
@@ -864,6 +864,7 @@ menu "Hardware handling"
  	source "package/ccid/Config.in"
  	source "package/dtc/Config.in"
  	source "package/gnu-efi/Config.in"
+	source "package/hidapi/Config.in"
  	source "package/lcdapi/Config.in"
  	source "package/libaio/Config.in"
  	source "package/libatasmart/Config.in"

package/hidapi/Config.in new file +20 -0

new file mode 100644
index 0000000..7fbc1c2
@@ -0,0 +1,20 @@
+config BR2_PACKAGE_HIDAPI
+	bool "hidapi"
+	depends on BR2_PACKAGE_HAS_UDEV
+	depends on BR2_TOOLCHAIN_HAS_THREADS # libusb
+	select BR2_PACKAGE_LIBUSB
+	# When eudev is used as the udev provider, libgudev is
+	# automatically provided as it is part of eudev. However, when
+	# systemd is used as the udev provider, libgudev is not
+	# provided, and needs to be built separately. This is why we
+	# select the libgudev package only if systemd is used.
+	select BR2_PACKAGE_LIBGUDEV if BR2_PACKAGE_SYSTEMD
+	help
+	  HIDAPI is a multi-platform library which allows an application
+	  to interface with USB and Bluetooth HID-Class devices on
+	  Windows, Linux, and Mac OS X.
+
+	  http://www.signal11.us/oss/hidapi/
+
+comment "hidapi needs udev /dev management and a toolchain w/ threads"
+	depends on !BR2_TOOLCHAIN_HAS_THREADS || !BR2_PACKAGE_HAS_UDEV

package/hidapi/hidapi.hash new file +2 -0

new file mode 100644
index 0000000..ba00df2
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 33e206f5e145fc1bc6aeb55084d71b55d686533d23ad5bb762746ceba81e728b  hidapi-d17db57b9d4354752e0af42f5f33007a42ef2906.tar.gz

package/hidapi/hidapi.mk new file +17 -0

new file mode 100644
index 0000000..23d5eab
@@ -0,0 +1,27 @@
+################################################################################
+#
+# hidapi
+#
+################################################################################
+
+# Use master version as the current stable is very old and some bugs
+# have been fixed since then.
+HIDAPI_VERSION = d17db57b9d4354752e0af42f5f33007a42ef2906
+HIDAPI_SITE = $(call github,signal11,hidapi,$(HIDAPI_VERSION))
+HIDAPI_INSTALL_STAGING = YES
+# No configure provided, so we need to autoreconf.
+HIDAPI_AUTORECONF = YES
+HIDAPI_LICENSE = GPLv3, BSD-3c
+HIDAPI_LICENSE_FILES = LICENSE.txt LICENSE-gpl3.txt LICENSE-bsd.txt
+
+HIDAPI_DEPENDENCIES = libusb

package/hidapi/hidapi.mk line 27

Quoted 10 lines

package/hidapi/hidapi.mk new file +10 -0

+# When eudev is used as the udev provider, libgudev is automatically
+# provided as it is part of eudev. However, when systemd is used as the
+# udev provider, libgudev is not provided, and needs to be built
+# separately. This is why we select the libgudev package only if systemd
+# is used.
+ifeq ($(BR2_PACKAGE_SYSTEMD),y)
+HIDAPI_DEPENDENCIES += libgudev
+endif
+
+$(eval $(autotools-package))

Hi Vicente,

This looks ok to me.

For embedded, it would be nice to be able to build with only one back-end (hidraw or libusb), but hidapi doesn't currently support building that way. One day I'll get there.

Thanks for doing this!

Alan.