[dogzilla]

I'm the lucky owner of a Walstreet PB and a Wacom ADB tablet, both of which I love. As you may or may not know, Wacom has stated that their OSX drivers won't support ADB tablets even with a USB adapter. I'm not about to buy a new Powerbook anytime soon, and I don't think a USB pc card will work under OSX for a while yet, and would confliuct with my Wavelan card anyway.

So, I'm curious if it's possible to write my own Wacom driver, and how hard it would be. I realize that .kext's probably involve deep magic, but I'm not really interested in learning everything chapetr and vers - I'm just interested in hacking something together that will map the tablet area to the screen area, and maybe allow me to map key combinations to the pen button.

I realize I'd have to wrangle the specs and maybe some code out of Wacom ( which shouldn't be impossible ). I'm new to programming the Mac, but I have some experience with C under Unix. I've worked through the "Learning Coca" book a few times and feel pretty solid with that, and have now moved on to more advanced topics.

Does anyone know of a similiar project in the works already? What are some resources that describe how to go about this? Are there any .kext "shells" available that I could plug code into? Any other suggestions?

Thanks in advance,

[Angus_D]

Extremely difficult to just dive into Kernel programming, AFAIK... Also note that you'll need 2 machines to do debugging.

[dogzilla]

Originally posted by Angus_D:
<STRONG>Extremely difficult to just dive into Kernel programming, AFAIK... Also note that you'll need 2 machines to do debugging.</STRONG>

I have two machines, so no problem there. Actually, I have about 6.

Why do you say kernel programming is difficult? I would think it'd actually be easier, given that you don't need to create an interface. I've been speaking with a guy who was going to write Thrustmaster drivers - he also has a Wacom and his opinion is it wouldn't be too difficult, especially given some example code. The question is will Wacom give out information or not.

[benh57]

Originally posted by Angus_D:
<STRONG>Extremely difficult to just dive into Kernel programming, AFAIK... Also note that you'll need 2 machines to do debugging.</STRONG>

Actually, you don't need 2 machines to do kext debugging at all. Kernel Extensions are dynamically loaded and unloaded.

It is not as hard as you think. I just grabbed the AppleUSBAudio.kext driver from the Darwin source, made a modification to reduce my iSub volume systemwide, compiled it, did
"kextunload AppleUSBAudio.kext", then
"kextload MyAppleUSBAudio.kext" and boom, it works.

The hard part is not the kernel extension-ness of it, it is learning the IOKit API and the binary formats involved with driver programming. You better know your bitfields and USB Spec documents and ADB spec documents. And that is not easy to learn in a few weeks.

(of course, two machines will help as far as getting traces after panics and such, but the info on the screen was enough for the 3 panics i caused.

[ 11-17-2001: Message edited by: benh57 ]

[Angus_D]

Originally posted by benh57:
<STRONG>Actually, you don't need 2 machines to do kext debugging at all.</STRONG>

Well you do if you need to do any serious debugging. Like attaching a debugger.

<STRONG>The hard part is not the kernel extension-ness of it, it is learning the IOKit API and the binary formats involved with driver programming. You better know your bitfields and USB Spec documents and ADB spec documents. And that is not easy to learn in a few weeks.</STRONG>

Also you're working in a restricted environment, all your memory is hard wired so you have to be extra-careful with resources, if you muck up you get an unfriendly kernel panic and you might have to reboot, etc.

[dogzilla]

Hmm. Well, this *is* starting to sound more and more complex. But still, what have I got to lose by not trying (except possibly all my data)?

Can anyone suggest some resources that I might be able to check out?

[Angus_D]

Originally posted by dogzilla:
<STRONG>Hmm. Well, this *is* starting to sound more and more complex. But still, what have I got to lose by not trying (except possibly all my data)?

Can anyone suggest some resources that I might be able to check out?</STRONG>

Darwin CVS has lots of sample code, probably including the ADB drivers for the keyboard and mouse. Join darwin-drivers@lists.apple.com, too.