DragonBoard Connected devices is wrong RRS feed

  • Question

  • Every USB device connected to that board is named "USB Keyboard"
    Tuesday, February 2, 2016 9:25 PM

All replies

  • Does this still occur with the latest build?
    Tuesday, March 8, 2016 7:17 AM
  • yes
    Tuesday, March 8, 2016 7:24 AM
  • Hi Cyberh0me,

    We have attempted to reproduce your issue and have plugged in three different devices and all show up independently. From the lab:

    We don’t see this here, my Dragon board sees 3 distinct connected devices.  Microsoft Nano Transceiver v2.0, Jabra BIZ 620 USB, and CSR8510 A10.

    Do you have any further details?



    Tuesday, March 8, 2016 10:14 PM
  • logitech k120 keyboard, logitech mouse (unknown type), sandisk cruzer, different usb drives all recognized as usb keyboard
    independent if i only connect one or two devices 

    Wednesday, March 9, 2016 8:47 AM
  • @cyberh0me,

    Confirming your findings,

    Running latest 10.0.10586.0 OS

    Default app reports 2x Mini Keyboard when I have plugged in 1x Rii Mini Keyboard + 1x CSR 4.0 Bluetooth Dongle. 

    If I hotswap the CSR 4.0 Dongle with my GN 2000 USB Microphone, I then see 2x GN 2000 MS USB Reported.

    Thursday, March 10, 2016 7:43 PM
  • Thanks for the confirmation Paul!

    Update: I have logged this issue into the IoT Team backlog for review.

    Thursday, March 10, 2016 8:29 PM
  • Thanks for the confirmation Paul!

    Update: I have logged this issue into the IoT Team backlog for review.

    thx, same with 10.0.14279.1000

    deviceInformationCollection in ConnectedDevicePresenter in IotCoreDefaultApp contains


    but the device.Name is always the same, in my case USB Keyboard

    the interesting thing is the name is also USB Keyboard if i only connect the mouse

    DeviceTree -> Devices contains the right information

    >USB Input Device
    (ID:USB\VID_046D&PID_C31C&MI_00\7&355A040C&0&0000, Class:HIDClass, Manufacturer:(Standard system devices), StatusCode:25165834)
      >HID Keyboard Device
      (ID:HID\VID_046D&PID_C31C&MI_00\8&269EF808&0&0000, Class:Keyboard, Manufacturer:(Standard keyboards), StatusCode:25165834)
    >Logitech USB WheelMouse
    (ID:USB\VID_046D&PID_C00C\6&18F0F8A0&0&2, Class:HIDClass, Manufacturer:Logitech, StatusCode:25174026)
      >Logitech USB WheelMouse
      (ID:HID\VID_046D&PID_C00C\7&3895C662&0&0000, Class:Mouse, Manufacturer:Logitech, StatusCode:25174026)

    Wednesday, March 16, 2016 1:04 PM
  • Hi CyberH0me,

    This issue is still in the backlog for review by the IoT Team and it contains a link to this forums thread so any information you provide is definitely helpful.

    Sincere thanks!


    Wednesday, March 16, 2016 5:05 PM
  • one thing to note is the name "USB Keyboard" if you compare the DeviceTree you will not find that name, based on the DeviceTree i would expect to see "HID Keyboard Device" and not "USB Keyboard"
    Wednesday, March 16, 2016 5:23 PM
  • Hi CyberH0me,

    Is this still occurring for you on the latest build?

    Sincere thanks,


    Friday, April 8, 2016 6:16 PM
  • yes, yes (2 times as the body must have at least 4 chars....)
    Friday, April 8, 2016 6:32 PM
  • Hi Cyberhome,

    This issue has been root caused down to the way the DragonBoard handles the USB queues and has been escalated to Qualcomm.



    Monday, October 17, 2016 6:29 AM
  • tested the new bsp (10.0.14993.1000) same issue
    Tuesday, January 3, 2017 12:03 AM
  • Hi Cyberhome,

    It seems like Qualcomm is unlikely to fix as there is no functionality issue caused by the naming and it is my understanding that there would be a significant change to their USB BSP architecture to change how the USB Queue is handled.  Are you hitting a functionality problem?



    Tuesday, January 3, 2017 6:54 AM
  • that discussion does not make sense

    it seems like Qualcomm is unlikely to fix Windows IoT Core related issues in general

    Tuesday, January 3, 2017 1:38 PM
  • Hi Cyberhome,

    There are a number of OEM devices based on IOTCore about to hit the market.  These OEMs worked directly with Qualcomm to get the BSP changes needed for their implementation and Microsoft recently received a drop based on those fixes but unfortunately, I do not have insight into which issues were addressed.  My point was, in this particular case, if the mis-named USB device failed to function that would be a very high priority to be fixed but if the device is working and only the name is wrong, that is likely a low priority for Qualcomm. 

    Again, I have no input into what Qualcomm decides is most important to be fixed.  My assumption would be that displaying the friendly name of a plugged in USB device is probably only interesting to developers and potentially not really relevant on a final single purpose embedded device.



    Tuesday, January 3, 2017 5:25 PM