How to use a custom USB device (WinUSB) on Microsoft HoloLens 2? - usb

I made a custom USB sensor device that runs on a Windows 8.1 / 10 desktop computer using the WinUSB driver (I implemented Microsoft extended USB descriptors in device firmware to automatically install the driver when the device connected).
Can I use a WinUSB device on HoloLens2? Or, if there is no WinUSB support on HoloLens2, how can I use my USB device with a “custom USB device class”?
At the moment, I do not have a hololens2, but I need to understand how the USB works on it.
Edit: I found this link: https://learn.microsoft.com/en-us/hololens/hololens-connect-devices#hololens-2-connect-usb-c-devices
It says that hololens2 supports the following device classes:
Mass storage devices (such as thumb drives)
Ethernet adapters (including ethernet plus charging)
USB-C-to-3.5mm digital audio adapters
USB-C digital audio headsets (including headset adapters plus charging)
Wired mouse
Wired keyboard
Combination PD hubs (USB A plus PD charging)
My device does not implement any of these classes (custom class). Is there a chance to make it work on hololens2?

I finally tested my code and USB device on real Hololens 2. The USB device works great there because Hololens2 supports WinUSB! The WinUSB driver was installed automatically (my device has WinUSB descriptors).

According to the documentation you referred, all classes HoloLens2 supports have been listed, and unlisted classes are not supported.
Could you provide more information about your business request and submit a feature request via feedback hub on new feature request to be considered in future releases of HoloLens OS and devices?
If it’s a hot impacted feature, it will be possible to be given priority to jump in the development schedule. Actually, the existing classed on HoloLens 2 are also based on user’s feedback in such way.
For how to post feedback request, you can follow this doc: Send feedback to Microsoft with the Feedback Hub app.

Related

on windows 7/8, how to read usb device descriptor from a usb camera, and read picture stream with webcam meanwhile

I use webcam-capture(java api) to get video stream from a usb camera, it work fine.
I want read a usb device descriptor(store some private information), i find out that should install WinUSB or libusbk as a driver to the usb devices. and it test ok, read the descriptor success (by libusb_control_transfer api)
the question is:
befor I install WinUSB, the usb camera is a camera device in the windows device management list. the LibUSB work fail, can't open the usb devices, the error number is -5, means entrypoin not find
after I install WinUSB, libUSB api work ok, but the webcam program can't open the usb devices, it is a universal usb device in the windows device management list.
is there some way the webcam work ok, at the same time, i can read the usb device descriptor use libusb or use other something?
i tested on windows 7 and windows 8, have the same problem.
thanks.
Sadly this is not possible because each of your applications needs a different driver. The only way this can work is if you use libusb and build you own capturing api on top which is quite complicated. As long as webcam-capture can not read the data you want to know about the webcam I am afraid this is not possible.

USB WebCamera protocol

When I plug a USB web Camera into a PC via USB, what communications is used? I know each device COULD have its own uniques driver, but it seems as though 99% use a common built in driver now. Where is it spec'd and how do you get a linux embedded device to act like a webcam?
What you're looking for is the USB Video Class and you can download the specification for this and other standard USB device classes here:
http://www.usb.org/developers/docs/devclass_docs/
The Linux USB gadget framework has code to emulate such a device:
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uvc.c

Does an HID device need libusbx Windows backend driver on Windows 7?

Current status:
I have developed some USB based device and have developed a driver on Linux using libusb. I am now porting the driver to Windows 7.
Device details
My device is a touch screen with two interfaces, one for the OS to communicate with the touch screen and the other for some vendor communication.
Old Stack Overflow post:
libusb_open returns 'LIBUSB_ERROR_NOT_SUPPORTED' on Windows 7
Here I was stuck with a problem that my libusb_open returned with an error. I learnt that I need Windows backend drivers. But I also learnt that it is for devices which are not recognised by the operating system.
Action taken
I tried installing a driver for my device using the Zadig tool, but I am not able to override the driver used by the OS with the new driver.
Do i really need a libusbx Windows backend driver for a device which has been identified and working well on windows 7? (The touch screen works perfect as a multitouch device)
What is the way forward as the device just can't be opened?
If you really use libusbx then you should be able to at least open the device for sure.
Make sure you did not mess the default HID driver for your device while playing with Zadig tool. Go to Control Panel/Device Manager/Hid section (is your device listed there?), search your device and remove the driver. Then try again.

Logitech Unifying Receiver Protocol?

Is there a place where I can find documentation or an SDK about the Logitech Unifying Receiver?
I recently obtained a wireless mouse, which came with a Logitech Unifying Receiver (a small USB dongle that plugs into the computer and communicates with the mouse/other compatible devices (such as keyboards)).
I wanted to try writing an app for my smartphone that pretends to be a mouse and sends data to the receiver.
I was able to monitor the data from the USB bus by using usbmon, and could probably use that to hack something out, but wanted to know if I could find the info I need somewhere on the internet without having to derive it on my own.
I'm going to try using SL4A on Android, if that helps any.
I have discovered some Logitech documents on a shared folder in Google Docs via this Chromium bug report. For convenience, I converted all doc(x) files to PDFs and put those on https://lekensteyn.nl/files/logitech/.
You will find Logitech HID++ 1.0 Specification for Unifying Receivers (pdf) very interesting, it describes the USB traffic (instead of the 2.4GHz wireless traffic as noted by Avery). My article Logitech Unifying for Linux: Reverse Engineering and unpairing tool documents a way to capture the traffic with usbmon and QEMU. It also includes tools to make the usbmon output prettier to read (for this protocol).
This is Avery, aka Tequals0. The USB dongle is a USB HID mouse/keyboard device, so all that traffic that you are seeing is basically generic HID traffic- if you want to pair your phone to your dongle, you will have to emulate the wireless traffic, not the USB traffic-that is generated by the dongle.
There is some info at Tequals0 blog, and AveryLouie also got some python tool operating with unifying

How to emulate USB devices?

The rest of my team will make for my application a simple non-standard USB microphone, but until they finish it I will have to emulate it, for integration testing purposes.
Is there any risk in a physical loopback? Yes there is
Will a physical loopback work? Only with a USB bridge
There is any way to create a logical loopback? (MSDN has something about this)
There is any general purpose USB emulator software?
In case there is many options available I'd rather work it .NET/Matlab/Python solutions.
Edit: Proof of concept here
I strongly recommend this project, USB IP. It is a way of connecting USB devices over the network. There is a Windows client.
What this means is, you install the client on your Windows computer.
This device then expects to talk to a USB device connected to a Linux computer, the server:
What you now do, is either create a fake device driver for Linux, that looks like is connected to a physical USB device, but in reality is just logic pretending to be your USB device. There are tutorials for writing USB drivers for Linux. Or you create your own stub driver for the Device Control Manager (see picture above). This stub driver could run on Windows or Linux, it wouldn't matter. It could even run on the same Windows machine which is the USB client.
The DSF USB Loopback Device mentioned in the question itself, would be the same kind of solution as a stub driver for the Device Control Manager, but taking Linux out of the picture altogether.
You can write virtual USB device using QEMU.
You can duplicate already existing device, like the dev-serial.c found in this QEMU repository and change it for your needs.
After you write and compile your USB device you can simply attach it to your VM using the QEMU command line interface.