How can I create a virtual HID device in code? I'm trying to avoid writing a kernel extension to accomplish this, but it seems to be the only way. I need to be able to create virtual HID devices of all types, and have an app running in the background feed them events. Is there a way to do this in user-space, or must I venture into kernel land?
The typical way of creating HID devices is to use the IOHID* classes in IOKit. You can write a userclient that passes events in and out.
I'm not sure what a "virtual" HID device is, however, I guess. If you want to create a keyboard on the screen, that sort of thing can probably be done in userspace.
Related
I would like to ask for guidance on how to ideally communicate with a custom USB HID device on MacOS.
Use case
Modify a microphone volume via an external USB HID device.
Question
Can I use DriverKit (HIDDriverKit) for that or I need to use IOKit? I have read something here about audio limitation, but not sure what exactly is not supported.
DriverKit doesn’t support USB devices that manipulate audio or that
communicate wirelessly over Bluetooth or Wi-Fi. For those types of
devices, create a kernel extension using IOKit.
— Source
Would DriverKit still work in my case as I am not sending audio streams but controlling volume only?
Many thanks!
Cheers,
Tom
If I understand you correctly, you wouldn't even need to use DriverKit. (from experience: avoid it if you can!)
You can communicate with HID-compliant devices directly from user space processes. User space processes can generally also control the volume on audio devices.
So by far the easiest option would be to have a launch agent which uses IOKit matching as its launch condition so it starts up when your device is connected. Your agent can communicate with the device using the IOHIDManager API to receive events when your buttons are pressed, and then use the regular Core Audio APIs to control volume.
It doesn't have to be a launch agent, incidentally: a regular Cocoa app with a UI can do all of this as well. (And indeed, you may want to show some form of UI as feedback to the user pressing the buttons.)
I am trying to write a program that emulates a gamepad in such a way that windows recognizes it as a gamepad, but it is actually controlled by my own code.
I have tried to create a virtual COM port and try to make windows recognize it as a gamepad, but without much luck.
Does anyone know a way to do something like this, or could maybe give me some pointers on what might be worth trying?
The HIDUSBFX2 sample driver (hidusbfx2.sys) demonstrates how to map a non-HID USB device to a HID device.
On Windows 10 there is new Virtual HID Framework (VHF) that is intended for same purpose.
So I'm look at sysfs for this. I'm looking at making a module/daemon that can read i2c devices and a couple of other things and export information in the filesystem for our main application.
For instance one of our io expanders is used as a board id, its a tca7408 but I don't need a GPIO interface to it. I just need to read it as an input and export the 0xXX number as an ID for userspace applications.
Just to add to this... is there a way to add custom data to sysfs? Or export application data to files similar to the functionality of sysfs?
If all of your devices are on i2c I would recommend creating a library with an easy to use API, things such as:
BoardId_t getBoardId();
Then you can hide all the i2c details in the library and reuse it where needed.
http://elinux.org/Interfacing_with_I2C_Devices
I tend to only write device drivers for things that actually NEED device drivers, in this case i2c already has a device driver so you can just use it. This will make your code easier to port to different versions of the linux kernel, and even different operating systems, and there is no need to mess with sysfs either.
I wonder if I understand correctly...
Say, if I want to control how my mouse work, i.e Left Button open window, Right Button send keystroke 'A' etc.
But I am not talking about writting something like follows in an application:
void MouseDown(xxxxEventArgs e, sender object)
{
}
I want to completely controls how the device work, then I will need to write a driver for it? From what I learn in assembly before, controlling a device I should need to know their port to communicate with the device. But say if I buy a Logitech mouse, is it possible to write a mouse driver myself to use it?
Because I saw some project that they buy a usb web cam from store, and they could able to control the web came to rotate, recevie the image from the web cam, I wonder if that's because the web cam has API provided them?
Thanks in advance.
If you want to control the device in it's entirety, then you need to write a device driver indeed. This is a non-trivial task and you should read up on it. There is a tutorial on it here and there a book for windows driver development here.
If you want to write device drivers, you should be very well versed with C and/or C++.
You do not need to write a device driver for what you are trying to do.The device driver has nothing but as per the data sheet of the device address of registers where it can read,write,do IOMMU etc or some other stuff.What you will need is some kind of hacking the application programming part of the thing which you are trying to achieve.
Because device driver code just reads the data from device and writes back it is the application which is concerned for it.Though in some case device driver programmer provide a method (function) to application programmer so that they can write their application and invoke those methods.In your case you need to just understand how the application code is talking to device driver.
In case you want to write a device driver check this
http://www.freesoftwaremagazine.com/articles/drivers_linux?page=0%2C0
In such kind of cases you can proceed with writing your own device driver by C++ and assemb
lyem
Do you know a way to use the Windows XP API to reset the USB bus? In other words, I'd like the OS to kick out any USB devices that are currently connected, and then auto-detect everything anew.
I'm aware of devcon, and I suppose I could do system calls out to it, but I'm hoping for a direct call into the API.
From kernel mode: You can force a specific USB device to be re-connected, as if it was unplugged and replugged again, by sending an IOCTL_INTERNAL_USB_CYCLE_PORT to its PDO. (This can only be done from a kernel mode, e.g. through a helper driver.) This 'cycle' operation will cause a USB reset to occur, after which the device would be re-enumerated. For example, if the device comes back with a different USB device descriptor, a different driver may be matched for it.
From user mode: You can do this by ejecting the device through the CfgMgr API. For example, to go over all USB hubs and eject all devices:
Find all devices having device interface GUID_DEVINTERFACE_USB_HUB with SetupDiGetClassDevs(... DIGCF_DEVICEINTERFACE).
Enumerate over the returned device information set (SetupDiEnumDeviceInfo).
For each device, get the DevInst member:
Invoke CM_Get_Child(DevInst) and then CM_Get_Sibling repeatedly to go over all child nodes of the hub (i.e. the USB devices).
For each child node, call CM_Request_Device_Eject.
Well, use can use the Setup API (SetupDiXXX functions) to enumerate the USB devices in the system, and then call WinUsb_ResetPipe on each one, but I'm not sure if that's what you're looking for. It's been a while since I worked with USB devices, but as I recall, there is no standard way to reset a device (i.e. simulate a power off/power on cycle). If it's possible for a particular device, you'd have to send an appropriate IOCTL (using DeviceIOControl) to the driver. The IOCTL would vary from manufacturer to manufacturer.
It's possible to cycle the parent port on the USB hub the device is attached to, as well. This will result in, among other things, apparrent unplug/replug actions, as you will see a balloon popup when this occurs.
Much of this is poorly documented, and honestly, I've gotten the impression there are only a handful of people at Microsoft who really understand it well. The design decision I've made for future devices I design is that I intend to include watchdog functionality on both sides, as well as a device-side full reset function. That way, if the device figures out it is confused, it can just cut its own power for a second and fully reset, if the host can't communicate with it, it could do the same thing, and if the device thinks everything is fine but the host knows better, the host could order it to reset.
There are at least three APIs worth looking into for this problem: the Setup API, the Config Manager API, and various WMI extensions. However, be cautious about diving into WMI if you intend to use an Embedded XP target, as you will have to include a lot of other things in your OS image you might otherwise not need.
As far as I know, there is no way to do this - you can issue a command to have PnP rescan the bus for new devices, but that isn't the same as issuing a bus reset.
Furthermore, just because from a hardware perspective you issued a bus reset doesn't mean that Windows will remove the PDOs that represent the children of the hub and redetect them; the USB bus driver can (and does) do just what I describe (i.e. issue hardware bus resets without disturbing the device tree), and only after the device doesn't respond does it issue the surprise removal and yank it from the tree.