[libhid-discuss] LIBHID: Latest SVN Trunk: hid_opening.c: hid_compare_usb_device(): product_id matched incorrectly

[c***@gmail.com]

Hi:

I ran into a situation with libhid where a USB product ID of 0x0501 was
matching on a USB device with a product ID of 0x0503. I narrowed it
down in hid_compare_usb_device() to the line below:
-----
((dev->descriptor.idProduct & match->product_id) == match->product_id)
-----

Tracing the values of the above, both match and dev descriptor, the
values were showing correct (0x0501, 0x0503), but still evaluating as
matched.

If I change the above code to just:
-----
(dev->descriptor.idProduct == match->product_id)
-----

Then the product ID's match correctly, and only 0x0501 matches 0x0501.
Any ideas on why 0x0503 would match 0x0501 on the original code?

Actual hex codes were set/used in the passed HIDInterfaceMatcher struct.

As a side note, the vendor ID did not experience this problem. Latest
SVN trunk (2015-04-19).

Thanks.


~ Chris

[Andrew Silverman]

My recollection is that this is already a known bug that was never officially patched, as evidently libhid has long since been considered obsolete in favor of newer HID libraries (http://www.signal11.us/oss/hidapi/). I have the same change in my own code that still works with the existing library.

-----Original Message-----
From: libhid-discuss [mailto:libhid-discuss-bounces+andrewsi=***@lists.alioth.debian.org] On Behalf Of ***@gmail.com
Sent: Sunday, April 19, 2015 7:15 PM
To: libhid-***@lists.alioth.debian.org
Subject: [libhid-discuss] LIBHID: Latest SVN Trunk: hid_opening.c: hid_compare_usb_device(): product_id matched incorrectly

Hi:

I ran into a situation with libhid where a USB product ID of 0x0501 was matching on a USB device with a product ID of 0x0503. I narrowed it down in hid_compare_usb_device() to the line below:
-----
((dev->descriptor.idProduct & match->product_id) == match->product_id)
-----

Tracing the values of the above, both match and dev descriptor, the values were showing correct (0x0501, 0x0503), but still evaluating as matched.

If I change the above code to just:
-----
(dev->descriptor.idProduct == match->product_id)
-----

Then the product ID's match correctly, and only 0x0501 matches 0x0501.
Any ideas on why 0x0503 would match 0x0501 on the original code?

Actual hex codes were set/used in the passed HIDInterfaceMatcher struct.

As a side note, the vendor ID did not experience this problem. Latest SVN trunk (2015-04-19).

Thanks.


~ Chris

_______________________________________________
libhid-discuss mailing list
libhid-***@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/

[Andrew Silverman]

If you're trying to rewrite the Linux tools for the ultimarc u360, I've already done it- posted on github under andrewsil1/ultrastik tools.

_____________
Andy




On Sun, Apr 19, 2015 at 9:15 PM -0700, "***@gmail.com" <***@gmail.com<mailto:***@gmail.com>> wrote:

Thanks Andrew and Charles for the responses.

@Andrew: At least now I know I'm not crazy :)

I'm working with a USB driver for a joystick that uses libhid. If I ever
have to rewrite it, I will definitely go down the HIDAPI route.

Much appreciated!


~ Chris

On 4/19/2015 9:18 PM, Andrew Silverman wrote:
> My recollection is that this is already a known bug that was never officially patched, as evidently libhid has long since been considered obsolete in favor of newer HID libraries (http://www.signal11.us/oss/hidapi/). I have the same change in my own code that still works with the existing library.
>
> -----Original Message-----
> From: libhid-discuss [mailto:libhid-discuss-bounces+andrewsi=***@lists.alioth.debian.org] On Behalf Of ***@gmail.com
> Sent: Sunday, April 19, 2015 7:15 PM
> To: libhid-***@lists.alioth.debian.org
> Subject: [libhid-discuss] LIBHID: Latest SVN Trunk: hid_opening.c: hid_compare_usb_device(): product_id matched incorrectly
>
> Hi:
>
> I ran into a situation with libhid where a USB product ID of 0x0501 was matching on a USB device with a product ID of 0x0503. I narrowed it down in hid_compare_usb_device() to the line below:
> -----
> ((dev->descriptor.idProduct & match->product_id) == match->product_id)
> -----
>
> Tracing the values of the above, both match and dev descriptor, the values were showing correct (0x0501, 0x0503), but still evaluating as matched.
>
> If I change the above code to just:
> -----
> (dev->descriptor.idProduct == match->product_id)
> -----
>
> Then the product ID's match correctly, and only 0x0501 matches 0x0501.
> Any ideas on why 0x0503 would match 0x0501 on the original code?
>
> Actual hex codes were set/used in the passed HIDInterfaceMatcher struct.
>
> As a side note, the vendor ID did not experience this problem. Latest SVN trunk (2015-04-19).
>
> Thanks.
>
>
> ~ Chris
>
> _______________________________________________
> libhid-discuss mailing list
> libhid-***@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
> http://libhid.alioth.debian.org/

[Andrew Silverman]

Everything's the same but internally I rewrote it to handle both flavors of the firmware based on the detected PID. The new PIDs use a hid output report to do all the stuff the old version did via control messages.

_____________
Andy




On Sun, Apr 19, 2015 at 10:11 PM -0700, "Christopher Becker" <***@gmail.com<mailto:***@gmail.com>> wrote:

That's too funny. You guessed by the product ID I suppose :). Thanks for rewriting that. I will definitely have a look. Are the command line options the same or is everything different?


~ Chris

On Sun, Apr 19, 2015 at 10:34 PM, Andrew Silverman <***@microsoft.com<mailto:***@microsoft.com>> wrote:
If you're trying to rewrite the Linux tools for the ultimarc u360, I've already done it- posted on github under andrewsil1/ultrastik tools.

_____________
Andy




On Sun, Apr 19, 2015 at 9:15 PM -0700, "***@gmail.com<mailto:***@gmail.com>" <***@gmail.com<mailto:***@gmail.com>> wrote:

Thanks Andrew and Charles for the responses.

@Andrew: At least now I know I'm not crazy :)

I'm working with a USB driver for a joystick that uses libhid. If I ever
have to rewrite it, I will definitely go down the HIDAPI route.

Much appreciated!


~ Chris

On 4/19/2015 9:18 PM, Andrew Silverman wrote:
> My recollection is that this is already a known bug that was never officially patched, as evidently libhid has long since been considered obsolete in favor of newer HID libraries (http://www.signal11.us/oss/hidapi/). I have the same change in my own code that still works with the existing library.
>
> -----Original Message-----
> From: libhid-discuss [mailto:libhid-discuss-bounces+andrewsi=***@lists.alioth.debian.org] On Behalf Of ***@gmail.com<mailto:***@gmail.com>
> Sent: Sunday, April 19, 2015 7:15 PM
> To: libhid-***@lists.alioth.debian.org<mailto:libhid-***@lists.alioth.debian.org>
> Subject: [libhid-discuss] LIBHID: Latest SVN Trunk: hid_opening.c: hid_compare_usb_device(): product_id matched incorrectly
>
> Hi:
>
> I ran into a situation with libhid where a USB product ID of 0x0501 was matching on a USB device with a product ID of 0x0503. I narrowed it down in hid_compare_usb_device() to the line below:
> -----
> ((dev->descriptor.idProduct & match->product_id) == match->product_id)
> -----
>
> Tracing the values of the above, both match and dev descriptor, the values were showing correct (0x0501, 0x0503), but still evaluating as matched.
>
> If I change the above code to just:
> -----
> (dev->descriptor.idProduct == match->product_id)
> -----
>
> Then the product ID's match correctly, and only 0x0501 matches 0x0501.
> Any ideas on why 0x0503 would match 0x0501 on the original code?
>
> Actual hex codes were set/used in the passed HIDInterfaceMatcher struct.
>
> As a side note, the vendor ID did not experience this problem. Latest SVN trunk (2015-04-19).
>
> Thanks.
>
>
> ~ Chris
>
> _______________________________________________
> libhid-discuss mailing list
> libhid-***@lists.alioth.debian.org<mailto:libhid-***@lists.alioth.debian.org>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/libhid-discuss
> http://libhid.alioth.debian.org/

[Charles Lepple]

On Apr 19, 2015, at 10:15 PM, ***@gmail.com wrote:

> Hi:
>
> I ran into a situation with libhid where a USB product ID of 0x0501 was matching on a USB device with a product ID of 0x0503. I narrowed it down in hid_compare_usb_device() to the line below:
> -----
> ((dev->descriptor.idProduct & match->product_id) == match->product_id)
> -----
>
> Tracing the values of the above, both match and dev descriptor, the values were showing correct (0x0501, 0x0503), but still evaluating as matched.
>
> If I change the above code to just:
> -----
> (dev->descriptor.idProduct == match->product_id)
> -----
>
> Then the product ID's match correctly, and only 0x0501 matches 0x0501. Any ideas on why 0x0503 would match 0x0501 on the original code?

http://lists.alioth.debian.org/pipermail/libhid-discuss/2008-February/000355.html

> Actual hex codes were set/used in the passed HIDInterfaceMatcher struct.
>
> As a side note, the vendor ID did not experience this problem. Latest SVN trunk (2015-04-19).

SVN trunk was last updated six years ago - development has ceased.

You may want to consider this library instead: http://www.signal11.us/oss/hidapi/

--
- Charles Lepple
http://ghz.cc/charles/