Creating a touch screen driver for OS X: where to start?

Question

OK, so I recently purchased the Acer T232HL touch screen to connect to my Macbook Pro as an additional monitor. To give you an idea, here is my setup .

OS X does not support this monitor in any way, as you can see in the screenshot that I actually run Windows 8 through VMware, which proxies a USB connection to Windows, where touch events are supported. But obviously this is not perfect.

There is at least one third-party driver for OS X, which looked somewhat promising, but it does not seem to support multitouch from this device, it is expensive, and, as a rule, the pain began to work to a small extent. There is also mt4j , but best of all I could say after running my examples, it does not support this device at all.

So, here is my question: what do I enter if I would like to write a driver for this thing? I am mainly a web developer with many years of experience with Ruby, Objective-C (and a bit of C), Javascript, etc. I never ventured into any kind of hardware programming, so from the surface it seems like an interesting, intimidating challenge.

I know, at some level, I need to read data from USB. I know that this will probably mean trying to rebuild any protocol they use for sensory events (maybe this will be completely custom?). However, I have no clue where to start - will it be a kernel extension? In C, I suppose? I would like to have a high level overview of the moving parts involved here.

Ultimately, I want to use the touch screen to control a specialized web interface (working in Chrome), so ideally I could proxy touch events directly in Chrome without the OS actually moving the mouse cursor to the touch position (so the UI leads myself, just like on the iPad), but no matter how technically possible, I would like to start with something working.

Answer 1

You want to start with the Apple I / O Kit documentation . You can hope that the touch screen is not completely ordinary, although there should be some part that is not a standard USB HID, or it will work already. If there are any linux drivers (or other open source), you will have the advantage that someone has already done some of the reverse development for you. As an alternative to the I / O set, you can also look at libusb , which can cause your brain to become smaller at startup. If you need to write kext, this may not help you anymore.

Regarding some of your specific questions:

will it be a kernel extension?

Maybe, maybe not. I'm not quite sure about the situation with Mac OS X drivers, but I wrote a lot of USB code for the entire USB space for OS X many years ago. Maybe you are lucky.

In C, I suppose?

Maybe. The I / O set itself is written in a subset of C ++, so you can probably use this too if you want.

Is it possible that this will be completely ordinary?

Unfortunately, yes, it is possible.

Good luck