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.
Related
I have just begun a new project. I'd like to make my own simplistic computer mouse, since i'd like to learn how to program hardwear drivers and understand the protocols the hardwear uses. I have experience in both desktop and microcontroller programming. However, I haven't got a clue about how to write drivers. I'm working on a mac with OS X and the mouse only needs to be able to talk with OS X. I expect to use a MSP430 microcontroller from TI. I intend to connect my mouse via USB. I simply want to be directed in the right direction not specific help with the coding, yet. :)
I therefor have a couple of questions:
Should I write my own driver or is it possible to use a standard one?
If yes, what kind of driver should be written and where do you begin?
What kind of data should be sent to the mac to say, "Hey, I'm a computer mouse"?
Which protocols should I read about?
You can check USB HID articles for OSX side and if there exists for MSP430.
I think that you can use any other driver, if you emulate same behavior of the target device on your MSP side.
I want to selectively block and unblock usb devices based on their serial number. We can write kernel extensions to achieve the same. But this seems complicated and risky. So I would like to know is there any easy way to achieve the same in cocoa?
"Easy Way" most probably not; though there may be an alternative method to using a kext, it likely would not be the most sensible way of tackling the issue. You could block all usb devices quite easily, but this isn't what you're asking.
I'd advise you to write a kernel extension, which isn't as hard as you may think. If you've not written one before, I recommend you read this book, which is predominantly concerned with writing kernel extensions.
No. You basically need to write a kext to do this.
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 need some advice on windows programming, MIDI and WDM. I am trying to write a small application that will sit in the sys tray and be advertised to the system as a MIDI In/Out device so that MIDI programs can send to it and it will convert the messages into a different format. I have been reading Cant's WDM book and scouring for information about writing device drivers, but don't know if I'm going down the right path.
I don't see yet how to:-
a) register my driver as MIDI capable (do I stick a ref to it in the registery and let the OS direct MIDI calls to the functionality in a dll?)
b) direct MIDI data through the my driver to my app, which is probably going to be too large to be a driver itself.
Any advice on where to start would be much appreciated.
thanks,
Pete
Windows MIDI drivers do not need to be implemented in the kernel, they can be implemented entirely in userspace as DLLs.
MSDN has some information about the functions you need to implement -
Audio Device Messages for MIDI - unfortunately it is somewhat lacking.
There used to be sample code for this kind of driver, as part of the NT4 DDK, but more recent releases of the DDK / WDK unfortunately don't include it any more.
Some better (though older) documentation and sample code can still be found after some searching:
Introduction to Multimedia Drivers (From NT4 DDK)
Sample MIDI Wine Driver for Mac OS X
Devices are enumerated (or simulated) by device drivers, not applications. What you see in the sys tray is an application icon. Hence, you will need to have both a driver and an app - you can't have one bit of compiled code acting as both.
On the driver side, you probably want to have a peek at the MSDN docs. This will answer part (a) of yopur question.
Assuming that you still would like to continue, (b) is best don by letting your application pull the data from the driver. That's far easier than the other way around - an application can trivially find a driver, but a driver has big problems finding a specific app (process)
If you are looking for a bit easier way to get started, there is a MIDI loopback driver out there, and the folks that make it also offer (or used to offer) a version of it that allows your program to communicate directly with the driver. This gives you the behavior you are looking for, where a program appears as a MIDI device. The loopback driver is at http://nerds.de/en/loopbe1.html. I don't see the developer page anymore, but if you contact them, you might be able to purchase a license to a driver that you can access directly without the loopback.
I thought I was a decent programmer until I tried writing gamepad code for OS X. Now I feel deeply useless.
Does anyone know of any code that I can legally use in my (non-free) game?
Is it really this hard to talk to a gamepad on OS X? What am I missing?
Check out the HID Manager, especially the new HID Manager APIs in Leopard. It's somewhat verbose, but the essence of it is that you can get callbacks when devices are attached and detached, and get callbacks when events from those devices are enqueued.
If you're working with Cocoa, Dave Dribin has DDHidLib which provides a nicer Objective-C API atop the HID Manager, and runs on Tiger as well.
Turns out the answer was Apple's HID_Utilities, which (somewhat) simplifies the job of talking to HID Manager.
John Carmack really hit the nail on the head when he said that Apple don't care about games...
The quickest way to get gamepad events on OSX is to use SDL, the game library.
You don't have to use the whole library, you can just init the joystick subsystem
and then poll or wait for SDL_JOYAXISMOTION and SDL_JOYBUTTONUP/DOWN events.
SDL has an LGPL license, so you can dynamically link to it in your non-free game.
Easy!
No code, but communicating with gamepads and the like is pretty straightforward with the InputSprocket mechanism. What was the precise problem you had?