Accessing USB avermedia DVBT Dongle A867 - usb-drive

I have a usb dvbt dongle that I want to connect to our STB. I could build and insert the modules but then want to acquire the TS and pump that to vendor sw for demux and decoding. How to grab the TS buffer or data from the avermedia device?

Related

Is there any way to detect last packet of Bulk OUT transfer in USB from Host to Device?

I develop the driver in Embedded Device that communicates via USB with Host (PC). Device implements CDC class on USB FS.
When I send data from Host to Device with the size more than MaxPacketSize I have never get any Zero Length Packet to terminate transaction in any case.
I have checked it with data size equal or not equal to MaxPacketSize multiply.
According to USB specification (USB 2.0 standard 5.8.3) Zero Length Packet should be send in this case.
I suppose that this is a matter of Windows driver - usbser.sys, but I have not found confirmation of this behaviour.
What I am asking is there any way to detect the last packet in Bulk OUT transfer from Host to Device or any way to setup the Host to send these ZLP packets in Bulk OUT transfer?

Windows 10 FT_OpenEx() API open error when insert/remove other USB device

We have device ""FT245R USB FIFO" USB to Seriel for communication from Windows 10 using D2xx driver.
FT_OpenEx() API works without any issue. But whenever user unplug/plug new USB device(Mass storage device) , during that time FT_OpenEx() API failed to execute, so handle invalid and our data communication interepted. Could you let us know what can I do further to resolve this issue ?
Note: I have opened handle using following command FT_OpenEx("FT245R USB FIFO", FT_OPEN_BY_DESCRIPTION, &handle), I open it everytime, whenever I need to talk with communication device. tried with seriel number of the device , but still communication fails when unplug/plug other USB device.

How does USB core decides which HCI driver to use for a USB device driver?

I am looking into USB device driver code. looks like all it does is to fill a URB message then calls usb_submit_urb() to pass the message to USB core functions once probe() is called upon matching PCI vendor/product ID.
However I am not able to figure out how USB core relates the device driver to correct HCI driver (xHCI, eHCI etc.)... what I found is most of HCI drivers register themselves as a platform driver which has a unique name, is that the identifier for usb core to correlate the device driver and host driver?
When you have usb 3.0 - then kernel uses xhci driver and doesn't need uhci, ohci or ehci drivers. In such configuration you have got only one hci driver and one hci host. Earlier in the USB 2.0 era there were 2 possible configurations:
ehci with companion controller (ohci or uhci)
ehci with transaction translator (TT)
In the first situation you need to have both drivers installed - for example ehci and uhci. In the second one only dedicated ehci driver was needed.
So currently when you have only xhci - it registers itself as the only usb host driver in linux system. Second thing - it is host driver function to request anything from usb devices - so usb host generates any requests to devices and it is responsible for maintenance of the answers from device. The xhci host driver registers his interrupt and memory area for request maintenance.
I think you need to take a look at this problem from the host (xhci) point of view, not from device point of view, because the host is the master in usb communication and the host initiates any requests. Device is only answering those requests.

How to get USB device descriptor by doing DeviceIoControl() directly on the device?

I want to get the Device descriptor of USB devices on my system. I am creating a userspace application in Windows(un-managed, native c++ ). From these descriptors, I want to identify billboard devices and parse billboard capability descriptor (parsing bos descriptor).
Here is my approach.
Get USB devices on a system by SetupDiGetClassDevs(&GUID_CLASS_USB_DEVICE,...)
Get device path of each device using SetupDiGetDeviceInterfaceDetail()
Use CreateFile() on device path to get handle to the device.
Issue IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION IOCTL using DeviceIoControl(), and the handle, to get the device descriptor.
I am stuck on the 4th step (getLastError() - Invalid Function).
Other projects (like this sample code from Intel), enumerate all USB controllers on the system, root hubs, ports, and interfaces, and issue IOCTL on the root hub's handle, specifying the port number to which a device is connected.
I do not want to concern myself with the USB hierarchy of the system.
It is less error-prone and easier to get USB devices in the system using setup API. However, nowhere I can see IOCTL being issued to them directly.
Update1
From learn.microsoft.com:
IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION I/O control request retrieves one or more descriptors for the device that is associated with the indicated port index. This request targets the USB hub device (GUID_DEVINTERFACE_USB_HUB). Thus this ioctl which can give me device descriptor of a USB device is meant to be handled by USB Hub, and NOT by a USB device.
Therefore the other solutions pass handle of hub to DeviceIoControl(), as can be seen on Line 68 of the source code from Intel (Linked here).
I instead want to use the handle obtained in step 3 (handle of the device) above to get the device descriptor. So, the IOCTL could be different, or possibly there is a way to get handle of the hub, and index of port to which the device is connected using the handle of the USB device.
The way I see it, device descriptor is an intrinsic property of a USB device, and therefore there must be a way to get it directly from the USB device.
Assuming you already have USB device handle first you need to get DEVPKEY_Device_Driver property string from it (by means of CM_Get_DevNode_PropertyW or SetupDiGetDevicePropertyW).
You'll receive string like {36fc9e60-c465-11cf-8056-444553540000}\0010.
Next you need to iterate over each USB hub in system (devices that have GUID_DEVINTERFACE_USB_HUB interface) and for each:
Open it via CreateFile() call
Call DeviceIoControl(hubInterfaceHandle, IOCTL_USB_GET_NODE_INFORMATION, ...) to get USB_NODE_INFORMATION structure that contains number of USB ports in its hubInfo.u.HubInformation.HubDescriptor.bNumberOfPorts
For each port from 1 (they are one based!!!) to bNumberOfPorts call DeviceIoControl(hubInterfaceHandle, IOCTL_USB_GET_NODE_CONNECTION_DRIVERKEY_NAME, ...) to get unique DriverKey of device connected to this port.
Compare DriverKey string you have on previous step with string you have from DEVPKEY_Device_Driver call. If they are same - congratulations you have found USB hub and port that have your USB device connected!
Now you can call DeviceIoControl(usbHubInterfaceHandle, IOCTL_USB_GET_NODE_CONNECTION_INFORMATION, ...) to get USB_NODE_CONNECTION_INFORMATION structure that contains USB_DEVICE_DESCRIPTOR!
Also you can additionally call DeviceIoControl(usbHubInterfaceHandle, IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION, ...) with USB_DESCRIPTOR_REQUEST to get other USB descriptors in addition to basic USB_DEVICE_DESCRIPTOR.
For example code see EnumerateHubPorts() and GetDriverKeyName() in official USBView sample.
Also I just did that in my RawInputDemo repo here.
UPDATE: There is easier way to get USB device number in a parent USB HUB - just get DEVPKEY_Device_Address property from a USB devnode.

why we need to create two device objects ( PDO and FDO) for a single device attached to bus?

i m new in windows , while reading WDM driver , i encountered about device object (PDO and FDO) .I m not able to visualize why we need 2 different device object as after loading the driver why we again create FDO in ADDDevice routine . we can use PDO there as it represents same device.
The PDO and the FDO have to be separate objects because they use different device drivers. For example, a PCI NIC device will have a PDO generated by the device driver for the PCI bus, and an FDO generated by the device driver for the NIC.
Occasionally the bus and the device do share the same driver, in which case you don't need an FDO. You can use a raw PDO, which combines a PDO and FDO in a single device object.
See Example WDM Device Stack in MSDN for a picture, and PDOs, part 1 for a short description.

Resources