Usbdk Driver X64

0 views

Skip to first unread message

Vinnie Frevert

unread,

Aug 4, 2024, 5:02:48 PM8/4/24

to nhomsijamlo

Forisochronous OUT endpoint , the libusb callback function not returning actual length it is transferring to the device. When I debug i found it is near "usbdk_helper.WritePipe(priv->redirector_handle, &transfer_priv->request, overlapped); " .

UsbDk.sys is both USB filter driver and generic USB device driver.

On installation it is being registered as USB filter driver and

system invokes it for each new USB device being discovered including

USB hubs. On invocation UsbDk.sys checks type of underlying device

and creates filter instances for USB hubs only.

Upon enumeration request completion by USB hub driver UsbDk.sys scans

array of child devices returned and in case there are devices to be

redirected (according to current configuration) it attaches as filter

to those devices as well.

Sure - to support virtualization. RHAT is putting lots of resources into

KVM. PV USB is part of that. Not clear how this works for them on the

client side, - perhaps they want to hang PV USB devices off of emulated

host controller root hubs?

The main purpose is to support USB devices redirection from Spice client machines to VMs. WinUSB had several limitations that we wanted to overcome. Including no support for isochronous transfer on older Windows versions.

spice-gtk is a GTK+3 SPICE widget. It features glib-based objects for SPICE protocol parsing and a gtk widget for embedding the SPICE display into other applications such as virt-manager or Boxes. Python and Vala bindings are available too.

Windows SPICE Guest Tools (spice-guest-tools) - This installer contains some optional drivers and services that can be installed in the Windows guest to improve SPICE performance and integration. This includes the qxl video driver and the SPICE guest agent (for copy and paste, automatic resolution switching, ...)

UsbDk (USB Development Kit) is an open-source library for Windows meant to provide user mode applications with direct and exclusive access to USB devices by detaching those from the Windows PNP manager and device drivers and providing user mode with API for USB-specific operations on the device.

A console is a graphical window that allows you to view the start up screen, shut down screen, and desktop of a virtual machine, and to interact with that virtual machine in a similar way to a physical machine. In Red Hat Virtualization, the default application for opening a console to a virtual machine is Remote Viewer, which must be installed on the client machine prior to use.

The Remote Viewer application provides users with a graphical console for connecting to virtual machines. Once installed, it is called automatically when attempting to open a SPICE session with a virtual machine. Alternatively, it can also be used as a standalone application. Remote Viewer is included in the virt-viewer package provided by the base Red Hat Enterprise Linux Workstation and Red Hat Enterprise Linux Server repositories.

usbdk is a driver that enables remote-viewer exclusive access to USB devices on Windows operating systems. Installing usbdk requires Administrator privileges. Note that the previously supported USB Clerk option has been deprecated and is no longer supported.

Just download and install the latest release (1.0.19 as of the moment of writing) and you are done. iPi Recorder can use Kinect v2 devices via libfreenect2. Moreover, because of the smart way UsbDk handles driver replacement you can still use other programs which work with Kinect in a standard way via MS Kinect SDK 2.0.

The first step is to install drivers from the coral website, but I'm getting the following errors. I've tried running with and without admin, and uninstalling and installing again, but I get the same errors.

This is a bug in the coral software. According to this thread -coral/edgetpu/issues/260 they messed up a few things in the newest version (at the time 2.5.0). Starting with a fresh virtual environment and using the release 2.1.0 and corresponding driver for Python 3.7 (3.8, 3.9 not supported as of 2.1.0) fixed the issue.

While we usually wait for a Progress Report to write about bug fixes and other features, a regression was causing so many issues that we've decided to roll out an early monthly build and detail what happened and why right now. If you're a heavy user of Dolphin's passthrough features, this is a rather important update.

libusb is an incredibly powerful library that facilitates direct communication to USB devices without needing to develop a kernel level driver. It also has the benefit of being cross platform between Windows, Linux, macOS, and even FreeBSD! Last Month, we saw a tremendous update to Passthrough support that fixed many issues on Dolphin's side and libusb's side, resulting in greater compatibility and stability among devices.

Unfortunately, things managed to break in another way due to some changes made to how Dolphin handles passthrough. Pretty much anyone on Windows using any sort of passthrough could potentially trigger one of the following issues, and it got particularly bad when multiple types of passthrough were combined.

If any of these conditions were triggered, Dolphin would usually crash. Sometimes, Dolphin could lock up and close without crashing, resulting in a ghost instance that would block any further instances of Dolphin from being able to use passthrough features until the user force closed the locked up instance. What caused this serious regression?

The problem stems from a change to how Dolphin handled each type of passthrough. With the latest batch of changes, Dolphin would use a single context for GameCube Controller Passthrough, Bluetooth Passthrough, and USB Passthrough. This was meant to simplify code and help accomodate usbdk users as it became unstable when we were using multiple contexts. In theory, everything should have been fine, as libusb was documented to be threadsafe in the situations we were going to be using it.

Unfortunately, this documentation is incorrect or we're misunderstanding it. While things weren't obviously wrong in isolated testing of each individual feature, it turns out that libusb would consistently deadlock when calling synchronous functions from multiple threads. The most common way to trigger this was by using two forms of passthrough at the same time. After over a week of investigation, we still have no idea if the fault is on our understanding of how libusb is supposed to work or a bug in libusb itself. Because we can't leave Dolphin in this state, we've decided to revert back to using multiple contexts and drop usbdk support.

We apologize to the sudden change in course, but this is a necessary step in providing a stable experience. These regressions, and subsequent fixes, should only affect users on Windows. At this point, we still recommend the libusbK driver, though, the WinUSB driver will also work for most devices. If you were already using one off those two drivers, you do not need to change anything, just update to the latest builds and the instability should be fixed. It is highly recommended that usbdk driver users uninstall the driver and switch to libusbK or winUSB.

I'm having an issue connecting my VirtualHere Linux console client to my 1fae:212c device plugged to my Win10 VirtualHere server, once I install the actual manufacturer's device driver on Win10. But, it works if I uninstall the manufacturer's device driver. Can you help take a look at my logs and give me any pointers? Thanks.

Issue: Using 'vhclientarm64 -t use' on Linux (client), I can successfully connect and use my device plugged to my Win10 machine (server). But, once I manually install the device drivers for 1fae:212c device on my Win10, then 'vhclientarm64 -t use' fails. It seems VirtualHere is incompatible if the actual device drivers are installed.

Workaround: Uninstall VirtualHere (and UsbDk drivers) before installing the actual device driver (needed to use the device with other programs). Or uninstall actual device driver before installing VirtualHere (and UsbDk drivers).

Thanks for the quick reply. I tried the version at the link above, but still getting errors now. Actually, I'm seeing failures now regardless of whether mfr driver is installed or not, whereas previous version worked for mfr driver uninstalled case. I collected server logs for the new server below (mfg drv installed and uninstalled case).

Do you know any idea to get past the 404 error? Just brainstorming, I'm thinking if I install mfr drivers are already installed, then VirtualHere doesn't need a driver install step (but, not sure of course..).

BTW - I understood your point about the incorrect venid/devid, good catch. Not sure why VirtualHere gets correct venid/devid with my original VirtualHere environment and without manufacturer drivers. I'm guessing VirtualHere somehow gives the device additional time to initialize before reading the Device Descriptor. Either way, I'll take it as a win :).

>Do you know any idea to get past the 404 error? Just brainstorming, I'm thinking if I install mfr drivers are already installed, then VirtualHere doesn't need a driver install step (but, not sure of course..).

Sorry, didn't word that right and couldn't edit. Let me try again:

Do you know any idea to get past the 404 error? Just brainstorming, but possibly can bypass the 404 by skipping the driver download, since mfr drivers are already installed (but, definitely not sure about this...). Thanks for your help.

As a check, I've setup environment #2 and hooked up WireShark to capture a USB trace. I see 2 enumerations occur for the 1fae:212c device after the 'use' command. In both enumerations, the DEVICE descriptor always returns 1fae:212c, so I'm not sure where 0000:0000 comes from in the server log. I'll try to attach the WireShark trace, in case it is useful.