TC1100 Tablet Enabler

[TC1100]

Dear All,

 

I am trying to the get the tablet of the TC1100 working with an iDeneb 10.5.5 install. Any help or guidance would be most appreciated.

 

 

Here is what I know....

 

HP released code for linux to do this, and this code cannot just be compiled, but needs to be ported to the OS X driver framework. Looking at the code, I believe all that needs to do is to write a single bit to the UART controlling the tablet, at which point it will identify itself as a serial port.

http://linuxwacom.sourceforge.net/index.php/howto/tabletpc (scroll down)

 

The ThinkPadTabletEnabler.kext kindly released by outZider for the ThinkPad X61 performs a similar task, although adjusting memory allocation rather than writing to the UART - I think. I have concluded this, based on reading the forum posts I found.

http://forum.insanelymac.com/index.php?sho...87574&st=60

 

Also, similarly to outZider's ThinkPadTabletEnabler.kext, if the enabler is loaded early enough in the boot process, then the operating system should pick up the port and it will work pretty seamlessly.

 

I am Java programmer some of the time, and so writing driver level code is s new experience for me, but I believe with some assistance I can get this working.

 

 

Here is what needs to be done....

 

(1) write and install a driver - done

(2) get it to load early enough in the boot process - still reading the documentation on this

(3) find equivalent to the 'outb' function, from the linux code, in the OS X driver framework - not even sure where to start reading

 

If I can get hold of a copy of the source of the ThinkPadTabletEnabler.kext, preferrably the whole Xcode project, then I believe step (2) will be solved. I have sent a 'personal message' to outZider asking for the source code, but have not heard back yet.

 

So, I am currently focussing on step (3). I have found an 'outb' function in the OS X driver framework, specifically the code dealing with serial devices. However, the function inputs appear to different - copy, paste, and compile does not work. I am either misunderstanding the functions operation, or it is signifcantly different and I need some other function? I suspect the later, but I am clueless where to find this information. I have googled quite extensively, but have been unsuccessful in find a guide for writing to UARTs for the driver kexts in OS X. Any ideas anyone?

[lazd]

Any luck with this? I'm a C programmer and I have a Cocoa/Carbon programmer friend, we might be able to do this...

 

Someone has posted a few jobs to GetAFreelancer.com about this...

 

http://www.getafreelancer.com/projects/C-C...ported-osx.html

http://www.getafreelancer.com/projects/C-C...le-for-OSX.html

 

I've been looking around trying to gather all the information I can, so let me know if you've discovered anything else.

[lazd]

After doing tons of research on everything from kexts to the IA-32 architecture, I think I've got something. I found an old archived blog entry about Steven Frank's attempts to enable the digitizer on the TC1100, and it inspired me and gave some good information.

 

The HP provided tablet enabling code is described as a 'standalone' in the comments. It's simply a set of commands that tell the tablet to enable the serial port. As long as it's ran before the actual 16X50 serial driver, and possibly with a setserial command in between, everything should fall into place.

Here's what we need:

 

1. Tablet enabler

A kernel extension will need to execute the HP provided code before the driver loads, so the serial port is available for use. There were some problems with missing functions, but I think I sorted it all out.

 

I found the equivalent outb() function required by the HP provided code in the architecture/i386/pio.h file, and the arguments it takes (port,data) seemed to match other implementations of outb(). What was more perplexing was finding an equivalent to iopl() -- it's very important. iopl() will change the EFLAGS register and give us access to use outb(). I found reference to an i386_iopl() function, but couldn't find the header file it was supposed to be included in (machine/sysarch.h). So I looked around -- I ended up finding a set_iopl_mask() function in the 2.6 kernel source... I adapted this function to take an integer instead of a mask, and bam -- we've got set_iopl_int().

 

I created a new Xcode project for a generic kernel extension, added all the code, included the set_iopl_int() function mentioned above, included the proper header files, and it compiles. I made sure the .kext was valid and had the proper dependencies

per the Apple tutorial here

and it seems to be ready to go.

 

I've attached the Xcode project and resulting kext -- it is 100% untested and I am totally unsure as to whether it will work. Please use caution when testing, but feel free to do so and report back.

2. We might need to do something with setserial

The Linux page mentions that you must run the HP provide enabler code then do a:

setserial /dev/ttyS2 port 0x03e8 autoconfig

To map the tablet to a serial port. I've seen setserial discussed in this context, and apparently TabletMagic may do everything we need by means of IOKit, but I'm not sure. I've gone ahead and compiled setserial for Mac OS X, but I'm not sure if it actually works.

 

See my post about compiling setserial

. I attached a binary that might work (along with the modified source file).

 

3. Serial Driver

As mentioned in Steven's blog entry: "The IONameMatch key in /System/Library/Extensions/Apple16X50Serial.kext/Contents/PlugIns/Apple16X50ACPI.kext/Contents/Info.plist must be modified to match the hardware ID of the digitizer. The correct vendor ID for the TC1100 appears to be WACF005."

 

4. TabletMagic

This is where the magic comes in.

------------------------------------------------------------------------

 

Tenative install steps:

 

0.

Download correct kext for your OS version from the attached files.

 

1.

Modify Apple16X50Serial.kext and Apple16X50ACPI.kext as mentioned above.

Apparently this will modify the kexts for you

. Look at the link to Steven Frank's old blog entry for more info.

 

2.

Ensure the owners for the kext attached are correct, install the kext

cp -R TC1100\ Tablet\ Enabler.kext /System/Library/Extensions/
sudo chown -R root:wheel /System/Library/Extensions/TC1100\ Tablet\ Enabler.kext

3.

Reboot. Make sure you pass the -f kernel flag or delete the kext cache before you restart

 

4.

Install TabletMagic and cross your fingers.

ONE LAST THING: If you try this, please run the following command at the terminal and paste the result:

kextstat

This will give insight into what extensions loaded.

 

I get my TC1100 in a few days and will post back with the results of my tinkering.

TC1100_Tablet_Enabler.kext.zip

TC1100_Tablet_Enabler.kext_10.4.zip

TC1100_Tablet_Enabler_Xcode.zip

tc1100ts_os_x.tar

setserial_osx_binary_and_src.zip

[TC1100]

WOW... is all I can say. You did all that. I only just noticed your message after replying to you PM.

 

I will get my machine back, which is with someone looking into this problem, and start testing your efforts.

 

THANKS. If your anywhere near London, UK, then it would be an honour to buy you a drink.

[lazd]

WOW... is all I can say. You did all that. I only just noticed your message after replying to you PM.

 

I will get my machine back, which is with someone looking into this problem, and start testing your efforts.

 

THANKS. If your anywhere near London, UK, then it would be an honour to buy you a drink.

Ah, it wasn't just me -- Steven's help has been indispensable. But you can still buy me that drink if I end up on the other side of the Atlantic!

 

Steven did quite a bit of testing, and ended up adding the HP provided code and the functions I adapted (and adding some additional logging) to the Apple16X50Serial kext source and built it in debug mode. He found where the problem is ocurring, but we don't know why or how to fix it yet. See below:

 

I installed Xcode 2.5 so I could build natively on the TC1100, and then downloaded the source to Apple16X50Serial corresponding to Mac OS 10.4.11. I built it using the DEBUG target.

 

You have to change a couple things to get it to compile. There's an undefined type "AbsoluteTime" which I simply changed to uint64_t. There was a debug logging function that didn't seem to do anything other than logging but didn't compile, so I just commented it out.

 

The build generates three Apple16X50 kexts (rather than one umbrella kext with "plugins" like the Apple-supplied one.) So, I deleted Apple16X50* from the Extensions folder, and put these three in its place. (Remembering to change to WACF005, chown to root:wheel, and clear kext caches each time)

 

When I rebooted, I could see the debug logging messages in /var/log/system.log after boot. So yay, my custom built 16X50 kext was loading.

 

By adding a bit more logging, I could see that this line was failing:

 

...in Apple16X50ACPI::start():

 

Map = provider->mapDeviceMemoryWithIndex(0);

if (!Map) goto fail;

 

The only reason it seems to need to do this is to get the base address of the UART, so I tried hardcoding it (the RegBase variable) to 0x03e8 (as documented in tc1100ts.c). I also inlined the code from the TC1100 Enabler right before that, so it would be an all-in-one kext without having to worry about order of loading.

 

On the next boot, it tried probing the UART 16 times to see what type of UART it was. That failed, so something is clearly not initialized properly.

 

(I tried hardcoding the UART type as well, and now I have a TC1100 that kernel panics on launch. Oh well, at least that's something new and different. )

 

But this feels like the right track... You can see the 16X50 driver load, try to probe the UART, and fail. Just gotta figure out why.

 

The 0x03e8 base address seems to be changeable -- if you look at these lines from tc1100ts.c:

 

wsio(0x60,0x03); // I/O Port Base [15-08]

wsio(0x61,0xe8); // I/O Port Base [07-00]

 

There's your 0x03e8 right there. So I guess it can be changed if it's somehow in conflict with something else.

 

----

 

Adding the tc1100ts.c code was just for completeness. It didn't noticeably change anything.

 

The 16 failed probes were because I commented out the failing call to mapDeviceMemoryWithIndex() and just assigned the value 0x03e8 directly to the RegBase variable instead. The 16 probe attempts are just the next thing that happens in the code (in Apple16X50UARTSync::probeUART(), where it tries to determine what type of UART it is.)

 

Presumably, if everything was set up right, you wouldn't need to comment anything out, because the mapDeviceMemoryWithIndex() call would succeed. Hardcoding the address was just a wild guess, which clearly didn't work.

 

I still can't say with any certainty if the code from tc1100ts is actually doing anything to the hardware or not. We'll have to determine that somehow.

 

Once the mapDeviceMemoryWithIndex() call fails in the 16X50 driver, it calls stop() on itself and pretty much just exits. And that's why you don't get an entry in /dev, I'm guessing.

...

The most important take-away is that mapDeviceMemoryWithIndex() call failing.

...

It sounds like the code from tc1100ts.c basically talks to it and says "ok, wake up, and pretend to be a UART at this base address". I can only assume that's not happening correctly at the moment.

So a bit of research has been done, but we're not sure if the HP provided code or the functions I hacked together do anything. Also, the kexts I posted are most likely useless, and the result will probably be a new version of the Apple16X50 kext with the enabler code inline. The tc1100ts.c and binary that implements the HP provided code, however, should work as a standalone if you'd like to do some testing with that.

 

I (should) get my tablet tomorrow and will most likely mess with this issue more next week.

 

I'll see if we can't get everything we have so far posted so others can check more into it.

 

Here's what I'm pondering:

 

1. Is there a way to see if the actual iopol() and outb() commands are taking effect, and to verify they're setting the IOPL level correctly and operating on the correct part of the EFLAGS register? I might be able to cook up some assembly to check this...

 

2. We need to find someone familiar with IOKit and serial stuff so we can figure out why the driver is failing...

3. In the HP provided code, the following was mentioned: "The serial device is mapped to 0x3e8 IRQ0-4 to match the default /dev/ttyS2 port and IRQ mapping on Linux." I have a feeling this is huge... We need to figure out where Mac OS X expects it to be mapped...

 

4. If we knew more about the "NS LPC SuperIO Specification" as mentioned in the HP provided code, maybe we would have more insight into how this all works in the first place...

 

-Larry

[TC1100]

Regarding point (1), I agree it would be very helpful, but I know no better than you where to start.

 

2. Yes, the problem of memeory address mapping as you mention, sounds similar to the problem OutZider solved for the Lenovo Tablet X61. There is some description of the steps he took in the forums.

 

3. I have always been preplexed by this issue, because how and why it comes up in the device listings, but cannot be mapped is strange. I even tried hacking the bios, which has to activate it for the touchscreen bios, and then deactivates it (god only knows why, I suspect MS windows). However, any hack I made to leave the ACPI device ON seemed to crash MS windows, and did not make any difference under OSX86 or Linux (Ubuntu).

 

4. You have lost me there. If we have the info to hardcode into a kext, then perhaps we need to follow the approach taken to hacking the serial kext to support the Aircard 555.

 

Regards

G

[TC1100]

Had a go with the enabler, but it did not work.....

 

Here is results of the kextstat.....

result.txt

[TC1100]

Had another go. I loaded the kexts manually after startup, and while they loaded, still no serial dev...

 

slateMac:Extensions g$ kextstat

Index Refs Address Size Wired Name (Version) <Linked Against>

1 1 0x0 0x0 0x0 com.apple.kernel (9.2.0)

2 24 0x0 0x0 0x0 com.apple.kpi.bsd (9.2.0)

3 3 0x0 0x0 0x0 com.apple.kpi.dsep (9.2.0)

4 38 0x0 0x0 0x0 com.apple.kpi.iokit (9.2.0)

5 42 0x0 0x0 0x0 com.apple.kpi.libkern (9.2.0)

6 35 0x0 0x0 0x0 com.apple.kpi.mach (9.2.0)

7 25 0x0 0x0 0x0 com.apple.kpi.unsupported (9.2.0)

8 1 0x0 0x0 0x0 com.apple.iokit.IONVRAMFamily (9.2.0)

9 1 0x0 0x0 0x0 com.apple.driver.AppleNMI (9.2.0)

10 1 0x0 0x0 0x0 com.apple.iokit.IOSystemManagementFamily (9.2.0)

11 1 0x0 0x0 0x0 com.apple.iokit.ApplePlatformFamily (9.2.0)

12 20 0x0 0x0 0x0 com.apple.kernel.6.0 (7.9.9)

13 1 0x0 0x0 0x0 com.apple.kernel.bsd (7.9.9)

14 1 0x0 0x0 0x0 com.apple.kernel.iokit (7.9.9)

15 1 0x0 0x0 0x0 com.apple.kernel.libkern (7.9.9)

16 1 0x0 0x0 0x0 com.apple.kernel.mach (7.9.9)

17 12 0x2df64000 0x10000 0xf000 com.apple.iokit.IOPCIFamily (2.4.1) <7 6 5 4>

18 10 0x2df7a000 0x4000 0x3000 com.apple.iokit.IOACPIFamily (1.2.0) <12>

19 5 0x2dfc1000 0x37000 0x36000 com.apple.driver.AppleACPIPlatform (1.0.3) <18 17 12>

20 0 0x2e043000 0x5000 0x4000 com.apple.BootCache (30.1) <7 6 5 4 2>

21 2 0x2e105000 0x39000 0x38000 com.apple.iokit.IOHIDFamily (1.5.3) <7 6 5 4 2>

22 0 0x2e16d000 0x3000 0x2000 com.apple.security.TMSafetyNet (3) <7 6 5 3 2>

23 0 0x2e187000 0x8000 0x7000 com.apple.nke.applicationfirewall (1.0.77) <7 6 5 4 2>

24 0 0x2e1c7000 0x18000 0x17000 com.apple.security.seatbelt (107.10) <7 6 5 3 2>

25 0 0x2e1f5000 0x4000 0x3000 com.apple.driver.AppleAPIC (1.1.0) <12>

26 0 0x3346d000 0x5000 0x4000 com.apple.driver.AppleSMBIOS (1.0.13) <12>

27 0 0x33624000 0x4000 0x3000 com.apple.driver.AppleACPIButtons (1.0.3) <21 19 18 7 6 5 4 2>

28 0 0x33669000 0x6000 0x5000 com.apple.driver.ApplePCIConfigurator (1.0.3) <18 12 5>

29 0 0x33701000 0x3000 0x2000 com.apple.driver.AppleACPIPCI (1.0.3) <19 18 17 12>

30 1 0x3375e000 0x3000 0x2000 com.apple.iokit.IOSMBusFamily (1.1) <6 5 4>

31 0 0x337af000 0x5000 0x4000 com.apple.driver.AppleACPIEC (1.0.3) <30 19 18 12>

32 1 0x337c2000 0x3000 0x2000 com.apple.driver.AppleEFIRuntime (1.1.0) <7 5 4>

33 0 0x337e3000 0x6000 0x5000 com.apple.driver.AppleEFINVRAM (1.1.0) <32 7 6 5 4>

34 0 0x3382d000 0x5000 0x4000 com.apple.driver.AppleRTC (1.0.6) <18 6 5 4 2>

35 4 0x33996000 0x18000 0x17000 com.apple.iokit.IOStorageFamily (1.5.2) <7 6 5 4 2>

36 0 0x339b3000 0x3000 0x2000 com.apple.driver.AppleFileSystemDriver (1.1.0) <35 5 4>

37 7 0x33a62000 0x28000 0x27000 com.apple.iokit.IOUSBFamily (3.1.5) <7 6 5 4>

38 0 0x33abb000 0xe000 0xd000 com.apple.driver.AppleUSBUHCI (3.1.5) <37 17 7 6 5 4>

39 0 0x33b60000 0x12000 0x11000 com.apple.driver.AppleUSBEHCI (3.1.5) <37 17 7 6 5 4>

40 0 0x33c04000 0x19000 0x18000 com.apple.iokit.IOPCCardFamily (1.6.4) <17 12>

41 3 0x33c8e000 0xd000 0xc000 com.apple.iokit.IOATAFamily (1.7.3f1) <6 5 4 2>

42 0 0x33cb4000 0x9000 0x8000 com.apple.driver.AppleIntelPIIXATA (2.0.0) <41 17 6 5 4>

43 0 0x33d08000 0x2000 0x1000 com.apple.iokit.IOUSBUserClient (3.0.7) <37 6 5 4>

44 0 0x33d6f000 0xb000 0xa000 com.apple.driver.AppleUSBHub (3.1.5) <37 6 5 4>

45 1 0x33e11000 0x19000 0x18000 com.apple.iokit.IOSCSIArchitectureModelFamily (2.0.4) <6 5 4 2>

46 0 0x33e4c000 0x4000 0x3000 com.apple.iokit.IOATAPIProtocolTransport (1.5.2) <45 41 12>

47 0 0x33ecb000 0xe000 0xd000 com.apple.iokit.IOATABlockStorage (2.0.0) <41 35 6 5 4 2>

48 0 0x33f39000 0x5000 0x4000 com.apple.driver.XsanFilter (2.7.91) <35 12>

49 0 0x38333000 0x4000 0x3000 com.apple.driver.AppleUSBComposite (3.0.0) <37 5 4>

50 0 0x383dd000 0x5000 0x4000 com.apple.iokit.IOUSBHIDDriver (3.1.0) <37 21 6 5 4>

51 1 0x2dee1000 0x1c000 0x1b000 com.apple.iokit.IOGraphicsFamily (1.5.2) <17 7 6 5 4>

52 0 0x2defd000 0xe000 0xd000 com.apple.iokit.IONDRVSupport (1.5.2) <51 17 7 6 5 4>

53 1 0x2df0f000 0x3000 0x2000 com.apple.kext.OSvKernDSPLib (1.1) <6 5>

54 2 0x2e048000 0x17000 0x16000 com.apple.iokit.IOAudioFamily (1.6.4b7) <53 6 5 4 2>

55 2 0x2df12000 0xd000 0xc000 com.apple.driver.AppleAC97Audio (1.0.0) <54 12>

56 0 0x2df1f000 0x4000 0x3000 com.apple.driver.AppleAC97AudioIntelICH (1.0.0) <55 17 12>

57 3 0x2e07f000 0x16000 0x15000 com.apple.iokit.IONetworkingFamily (1.6.0) <7 6 5 4 2>

58 0 0x2e02d000 0x6000 0x5000 com.apple.driver.AppleBCM440XEthernet (1.2.0) <57 17 6 5 4 2>

59 0 0x2e033000 0x4000 0x3000 com.apple.driver.AudioIPCDriver (1.0.4) <54 6 5 4 2>

60 0 0x2e037000 0x4000 0x3000 com.apple.driver.AppleACPIPowerSource (1.0.3) <19 18 12>

61 0 0x2e095000 0x4000 0x3000 com.apple.driver.AppleACPIThermal (1.0.3) <19 18 12>

62 1 0x2e099000 0x1d000 0x1c000 com.apple.iokit.IO80211Family (153.2) <57 7 6 5 4 2>

63 0 0x339b6000 0x62000 0x61000 com.apple.driver.AirPortAtheros5424 (120.31.1) <62 57 17 7 6 5 4 2>

64 1 0x3362c000 0x9000 0x8000 com.apple.driver.AppleSMC (2.0.1d2) <18 7 6 5 4>

65 0 0x2e03b000 0x3000 0x2000 com.apple.Dont_Steal_Mac_OS_X (6.0.2) <64 7 5 4 2>

66 0 0x2de9d000 0x2000 0x1000 com.apple.driver.AppleAC97CodecAD198x (1.0.0) <55 12>

67 0 0x2dea5000 0x2000 0x1000 com.apple.dsmos (1.0.0d1) <7 5 4 2>

68 0 0x33704000 0x10000 0xf000 com.apple.driver.DiskImages (195) <35 7 6 5 4 2>

69 0 0x2e168000 0x3000 0x2000 com.apple.iokit.KLog (3.0.3) <37 5 4 2>

70 0 0x38400000 0xb000 0xa000 com.apple.filesystems.autofs (2.0.1) <7 6 5 4 2>

71 0 0x33963000 0x3000 0x2000 com.bresink.driver.BRESINKx86Monitoring (3.0) <12>

74 1 0x33ff4000 0x9000 0x8000 com.apple.iokit.IOSerialFamily (9.1) <7 6 5 4 2>

77 0 0x33fca000 0x2000 0x1000 com.lazd.kext.TC1100TabletEnabler (1.0.0d1) <12>

79 1 0x33ffd000 0x9000 0x8000 com.apple.driver.Apple16X50Serial (1.9) <74 17 12>

80 0 0x33fa8000 0x2000 0x1000 com.apple.driver.Apple16X50ACPI (1.9) <79 18 12>

slateMac:Extensions g$