Unable to retrieve bus_type for some devices on Windows #502

New issue

Open

opened 2023-02-04 11:37:57 -06:00 by AlexGuo1998 · 6 comments

AlexGuo1998 commented

2023-02-04 11:37:57 -06:00

(Migrated from github.com)

On windows, we currently inspect the parent devnode to get bus_type:

github.com/libusb/hidapi@4ebce6b505/windows/hid.c (L498-L552)

However, some filtered HID device (e.g. imbushuo/mac-precision-touchpad) whose parent is the filter driver, which don't have a correct compatible_id. The device tree is like this:

...                                           (page usage)
Microsoft Bluetooth Enumerator
|- Bluetooth HID device                                   <- 3
   |- Apple Multi-touch Auxiliary Services    (FF00 0014)
   |- Apple Multi-touch Trackpad HID Filter               <- 2
      |- Microsoft Input Configuration Device (000D 000E)
      |- HID Compactible Trackpad             (000D 0005) <- 1

If we want to know the bus_type for (1), according to the code, we're inspecting the compatible_id for (2), which is empty.

However if we go one step further we hit (3), which has the correct compatible_id: BTHENUM\{GUID}. Now we know it's a Bluetooth device.

I suggest we go all the way up, until to the root to find a recognizable compatible_id, and stop after we found one.

I don't really know if this is the correct / sane thing to do. Could you give me some ideas?

BTW, on a UEFI laptop some devices have a ancestor with a compatible_id like *PNP0A03, but no more recognizable value. Do you know what that is? (Maybe we can open another issue for this?)

On windows, we currently inspect the parent devnode to get `bus_type`: https://github.com/libusb/hidapi/blob/4ebce6b5059b086d05ca7e091ce04a5fd08ac3ac/windows/hid.c#L498-L552 However, some filtered HID device (e.g. [imbushuo/mac-precision-touchpad](https://github.com/imbushuo/mac-precision-touchpad)) whose parent is the filter driver, which don't have a correct `compatible_id`. The device tree is like this: ``` ... (page usage) Microsoft Bluetooth Enumerator |- Bluetooth HID device <- 3 |- Apple Multi-touch Auxiliary Services (FF00 0014) |- Apple Multi-touch Trackpad HID Filter <- 2 |- Microsoft Input Configuration Device (000D 000E) |- HID Compactible Trackpad (000D 0005) <- 1 ``` If we want to know the `bus_type` for (1), according to the code, we're inspecting the `compatible_id` for (2), which is empty. However if we go one step further we hit (3), which has the correct `compatible_id`: `BTHENUM\{GUID}`. Now we know it's a Bluetooth device. --- I suggest we go all the way up, until to the root to find a recognizable `compatible_id`, and stop after we found one. I don't really know if this is the correct / sane thing to do. Could you give me some ideas? --- BTW, on a UEFI laptop some devices have a ancestor with a `compatible_id` like `*PNP0A03`, but no more recognizable value. Do you know what that is? (Maybe we can open another issue for this?)

Youw commented

2023-02-04 17:12:33 -06:00

(Migrated from github.com)

is #464 of any relevance to the issue described here?

AlexGuo1998 commented

2023-02-04 18:30:31 -06:00

(Migrated from github.com)

I'm not quite sure but maybe no.

In this situation, we don't even find USB in any of the compatible_ids, while #464 attempts to add some extra logic in if(wcsstr(compatible_id, L"USB") != NULL)

I'm not quite sure but maybe no. In this situation, we don't even find `USB` in any of the `compatible_id`s, while #464 attempts to add some extra logic in `if(wcsstr(compatible_id, L"USB") != NULL)`

JoergAtGithub commented

2023-02-05 02:30:06 -06:00

(Migrated from github.com)

@DJm00n can you help with this Bluetooth bus_type issue?

Youw commented

2023-02-05 08:47:12 -06:00

(Migrated from github.com)

I suggest we go all the way up, until to the root to find a recognizable compatible_id, and stop after we found one.

This does sounds like a good solution. But I guess i has to be in line with other changes (including #464).

> I suggest we go all the way up, until to the root to find a recognizable compatible_id, and stop after we found one. This does sounds like a good solution. But I guess i has to be in line with other changes (including #464).

DJm00n commented

2023-03-13 15:26:40 -05:00

(Migrated from github.com)

@AlexGuo1998 thank you for reporting. I'll review cr = CM_Get_Parent(&dev_node, dev_node, 0); after #464 get merged.

PS: according to the C:\Windows\INF\pci.inf PNP0A03 is a "PCI Bus".

@AlexGuo1998 thank you for reporting. I'll review `cr = CM_Get_Parent(&dev_node, dev_node, 0);` after #464 get merged. PS: according to the `C:\Windows\INF\pci.inf` `PNP0A03` is a "PCI Bus".

👍 1

mcuee commented

2023-05-01 22:29:52 -05:00

(Migrated from github.com)