I am trying to find out how I should go about making my own gamepad compatible with windows based games. I have used some time to read up on windows drivers but I feel kind of lost and unsure about how I should solve my problem. What i am asking for is some guidance toward what kind of solution or approach I should take.
So I have made a Arduino based GamePad which communicates with the computer over serialport(usb). From here I assume I need to make a driver which identifies itself as a GamePad(Device driver, Plug and Play driver)? I am not sure if I am done at this point or if I have to be compatible with DirectInput somehow?
-Michael
Forum thread about arduino and ppJoy virtual joystick.
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1210699098
I am planing to spend few days a week writing a driver for a Greenpacket USB WiMax modem. Greenpacket only provides Windows driver with it and as I am fond of Linux and Mac I feel very bad not having driver for them.
I have experience writing C++ programs so I think it won't be hard for me. Even I like C++ programming very much. I have never written drivers but I know some concepts. I have PDF of the device specification from the company's website.
I would like to ask if I can write driver with that provided specifications? If yes what would be my starting point assuming I would like to write it for MAC first and then Linux. I am reading this article right now but your experiences would be of great help.
The product specifications sheet does not provide enough data to write a device driver. You are going to need low-level information about how to speak with the WiMax device via USB. You are probably also way out of your depth of you think a product sheet is enough information to write a device driver.
I know this probably is not the easiest thing to do, but I am trying to connect Microcontroller and PC using USB. I dont want to use internal USART of Microcontroller or USB to RS232 converted, its project indended to help me understand various principles.
So, getting the communication done from the Microcontroller side is piece of cake - I mean, when I know he protocol, its relativelly easy to implement it on Micro, becouse I am in direct control of evrything, even precise timing.
But this is not the case of PC. I am not very familiar with concept of Windows handling the devices connected. In one of my previous question I ask about how Windows works with devices thru drivers. I understood that for internal use of Windows, drivers must have some default set of functions available to OS. I mean, when OS wants to access HDD, it calls HDD driver (which is probably internal in OS), with specific "questions" so that means that HDD driver has to be written to cooperate with Windows, to have write function in the proper place to be called by the OS. Something similiar is for GPU, Even DirectX, I mean DirectX must call specific functions from drivers, so drivers must be written to work with DX. I know, many functions from WinAPI works on their own, but even "simple" window must be in the end written into framebuffer, using MMIO to adress specified by drivers. Am I right?
So, I expected that Windows have internal functions, parts of WinAPI designed to work with certain comonly used things. To call manufacturer-designed drivers. But this seems to not be entirely true becouse Windows has no way to communicate thru Paralel port. I mean, there is no function in the WinAPI to work with serial port, but there are funcions to work with HDD,GPU and so.
But now there comes the part I am getting very lost at. So, I think Windows must have some built-in functions to communicate thru USB, becouse for example it handles USB flash memory. So, is there any WinAPI function designed to let user to operate USB thru that function, or when I want to use USB myself, do I have to call desired USB-driver function myself? Becouse all you need to send to USB controller is device adress and the infromation right? I mean, I don´t have to write any new drivers, am I right? Just to call WinAPI function if there is such, or directly call original USB driver. Does any of this make some sense?
To make your life easier, and avoid writing your own driver, try using the HID (Human Interface Device) API on top of USB. Although it says "Human Interface", it doesn't actually have to be for devices that a human controls. The advantage is that modern OSes already come with a HID driver and you can use sample code such as what you can find here to get started. Many microcontroller manufacturers provide suitable code for the embedded of the protocol.
Because OSes already understand HID, if you build a device using the HID interface you'll find that not only can you read from it from any OS, you may also find that many applications can already talk to your device if its communication is restricted to a small enough subset of HID. (For example, I built an input device for a music app, but amazingly I found I could literally plug it straight into a 3D animation app we use at work, running on a different OS, and have it work right away without writing a single additional line of code!)
This answer might aim you in the right direction.
The first answer here might also be helpful.
The answers to this have some actual code and links to yet other resources.
USB includes a set of stock functionality, much like supporting USB flash drives (USB Mass Storage class). The two most interesting for microcontroller interfacing are HID and CDC. CDC is easiest to use as it directly emulates an old fashioned serial port.
If you configure the microcontroller to act as a CDC device, Windows will enumerate it as a serial port, and all the old serial APIs will work on it.
My application needs to behave as a virtual joystick (imagine dragging a square with the mouse and translating that to the output of an analog joystick) and send some keystrokes over the network to another computer where the driver would receive that input.
I only need to support XP, Vista and Win7.
Maybe it can be done without writing a driver. I tried sending keystrokes with SendKey() which seemed to work but don't know how to emulate an analog joystick.
I've downloaded the VDK and been reading everything I can find on the subject but there are lots of things I still don't understand. Can you please point me in the right direction?
Should I build a kernel-mode or user-mode driver?
Can my driver act as a server for an app on the network?
Do you know good tutorials / books / samples that can help me with this.
Thanks
First of all you will have to have some kind of interface between your computer (or the network) and the joystick device that is being controlled.
If it involves making custom hardware to control the analog joystick (like it controls pneumatics or hydraulics or something, not just a pc game joystick type thing), then yes, you will almost certainly need a driver to allow a network app to move (the robot arm, or whatever) will move that joystick.
If you are able to remove the physical joystick from the equation, maybe you can write software that emulates the input of wherever the joystick used to plug into (a joystick/serial port?), or emulates it completely (a reasonably simple driver could do this). You could do it completely without writing a driver if the joystick used a standard communication interface (like RS232) because libraries exist that will handle all that and you can set up virtual COM ports that will be indistinguishable to whatever you are trying to communicate with.
The best book you can buy on driver development at the moment is Developing Drivers with the Windows Driver Foundation
Rootkits: Subverting the Windows Kernel is another great book, but doesn't cover a lot of the newer WDF stuff. It has more of a security focus but has a few awesome chapters on device drivers with fully spoonfed examples, breaking it down in a really accessible way.
If it is only over the network, probably simple socket programming should be enough.
How can I inject USB device nodes into OSX (>= 10.5) such as you might be able for debugging USB handlers / writing new USB drivers?
I'm interested in this in order to handle non-USB devices using TokenD.
From what it looks like, I would have to tackle faking USB-device insertion and then create a PC/SC ifdHandler that would handle this fake device. (If anyone knows of any other way to inject a not-necessarily-device-backed TokenD, let me know!).
I'm guessing IOKit may be involved in this solution... as that is the underlying item I need to 'trick'.
IOKit is pretty much the only thing involved, and you'll have to get a good grip on how it works before more specific answers will make any sense. If Apple's documentation doesn't do it for you, Amit Singh's book should pick up a lot of the slack, even if it is a little bit dated.