From WineHQ Wiki
Revision as of 00:25, 8 April 2022 by Zf (talk | contribs) (initial documentation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Wine includes some limited support for direct hardware access, including running native Windows drivers. This comes with several restrictions, but we still have been able to successfully access some native devices.


  • Wine runs in user space, and therefore cannot access any hardware that the kernel does not expose a user-space interface for. Depending on operating system this can be prohibitive, although Linux exposes interfaces for many common protocols, including PCI, USB, serial and parallel ports.
  • Wine cannot drive hardware that is currently being driven by the host operating system. This means, for instance, that we cannot drive keyboard and mouse devices, or GPU or network drivers, without disabling them on the host side, and hence making them unusable for applications not being run through Wine.
  • We are unlikely to implement support for common classes of devices which are usually accessed through a higher-level API, including but not limited to: GPU, network, mass storage, keyboard and mouse, audio, camera. If such devices are unsupported or poorly supported, effort should be spent on bringing up support for the host system instead. Efforts to support direct hardware access in Wine are mostly about domain-specific (and often obsolete) hardware, which it would be difficult and not particularly worthwhile to reverse-engineer host drivers for.
    • Although part of the problem here is accessing hardware which is usually also being driven by the host system (as in the above restriction), another part is about hooking up access via high-level Win32 APIs. For example, we implement Win32 sockets directly on top of POSIX sockets; implementing the infrastructure required to run NT network drivers, and hooking up Win32 sockets to these, would be a massive undertaking, and due to the design of kernel drivers in Wine it would likely have negative performance impact. In many cases the kernel interface is also undocumented, adding to the difficulty.
  • Hardware that is being driven through wine can only be accessed through Windows programs, and cannot be accessed from host programs outside of Wine. E.g. in some cases it is possible to use Wine to run HID drivers, but those HID devices will only appear to Windows programs run through Wine, and not to other programs on the host operating system.
  • Some native NT drivers require kernel interfaces that we cannot support. (One notable example of this is the ability to access user space memory via METHOD_NEITHER ioctls that contain pointers.)
  • As of the time of this writing (April 2022), support for direct hardware access has received limited testing and limited attention. Only a small number of protocols have been hooked up to any degree. Many interfaces are also missing. It's worth mentioning also that there are plenty of bugs affecting driver installation. If an appliation doesn't work, and you believe it should be able to work—considering the above restrictions—please report a bug.


As of April 2020, Wine includes support for USB kernel drivers. This requires a functional libusb 1.0 on the host, including at compile time. As of the time of writing (April 2022), user space access via winusb.dll is not yet implemented.

Depending on operating system and configuration, you may need to ensure that Wine has permission to access the device in question.

On Linux, this means read/write access. This can be done via a udev rules file. Refer to the udev(7) manual page for full documentation. For quick testing, though, the following file, placed as /etc/udev/rules.d/99-usb.rules will grant full read/write access to the specified device to all (world) users:

SUBSYSTEM=="usb", ATTR{idVendor}=="1234", ATTR{idProduct}=="abcd", MODE="0666"

Safer is to set up a separate group and use the GROUP="mygroup" directive, and then restrict the mode to 0664.

You may need to make sure that your rules apply last, after those shipped by the distribution, hence using a high number such as 99 will help.

Replace 1234 and abcd with the actual hexadecimal ID of the device. This can be found using lsusb.


Wine includes support for HID kernel drivers, and user-space access via hid.dll and via direct ioctls.

There should be some documentation here.

Serial and parallel ports

Wine includes support for serial and parallel I/O via user space. Support for kernel drivers is not implemented.