Hi All,
I've been investigating for a while now if it was possible to use the I2C Touchscreen and Windows Ink pen as input devices under OSX on my HP Spectre X360 which is currently running MacOS Sierra (10.12.6) - I have the 2017 15" 17-7500U Kaby Lake model with the 4K screen. HP Model number
15-bl001na.
Please note that this is not a complete guide on how to implement OSX support for I2C devices but an overview of how I investigated the I2C touchscreen and pen device's on my laptop and subsequent findings once the devices were working in OSX.
Examining the 2017 HP Spectre X360 I2C Architecture
This laptop uses an Intel Sunrise Low Power I2C Controller as part of its onboard chipset, it is this device that provides a five channel I2C bus to the Kaby Lake PCI bridge chip ... we can find out its PID & VID values using DCPIManager :-
View attachment 314035
We can further examine the I2C HID Controller and attached devices using Windows device manager:-
View attachment 314055 View attachment 314056
In the left screen garb we can see that the touchscreen (and pen) have a device parent of ELAN22CA ... this is the I2C device controller used to connect the screen and pen's physical interface to the on board I2C Bus.
In the right screen grab we can see that the I2C HID device has a ACPI name of TPL0, with this information we can now check that the device is correctly defined in the DSDT. The ACPI code for the TPL0 device on the 2017 HP Spectre X360 looks like this :-
Code:
Scope (_SB.PCI0.I2C0)
{
Device (TPL0)
{
Name (HID2, Zero)
Name (SBFB, ResourceTemplate ()
{
I2cSerialBusV2 (0x004C, ControllerInitiated, 0x00061A80,
AddressingMode7Bit, "\\_SB.PCI0.I2C0",
0x00, ResourceConsumer, _Y24, Exclusive,
)
})
Name (SBFG, ResourceTemplate ()
{
GpioInt (Level, ActiveLow, Exclusive, PullDefault, 0x0000,
"\\_SB.PCI0.GPI0", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0000
}
})
Name (SBFI, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, _Y25)
{
0x00000000,
}
})
CreateWordField (SBFB, \_SB.PCI0.I2C0.TPL0._Y24._ADR, BADR) // _ADR: Address
CreateDWordField (SBFB, \_SB.PCI0.I2C0.TPL0._Y24._SPE, SPED) // _SPE: Speed
CreateDWordField (SBFI, \_SB.PCI0.I2C0.TPL0._Y25._INT, INT2) // _INT: Interrupts
CreateWordField (SBFG, 0x17, INT1)
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
If (LLess (OSYS, 0x07DC))
{
SRXO (GPLI, One)
}
Store (GNUM (GPLI), INT1)
Store (INUM (GPLI), INT2)
If (LEqual (SDM1, Zero))
{
SHPO (GPLI, One)
}
Store ("ELAN22CA", _HID)
Store (One, HID2)
Store (0x10, BADR)
Store (0x00061A80, SPED)
Return (Zero)
}
Name (_HID, "XXXX0000") // _HID: Hardware ID
Name (_CID, "PNP0C50") // _CID: Compatible ID
Name (_S0W, 0x04) // _S0W: S0 Device Wake State
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
If (LEqual (Arg0, HIDG))
{
Return (HIDD (Arg0, Arg1, Arg2, Arg3, HID2))
}
If (LEqual (Arg0, TP7G))
{
Return (TP7D (Arg0, Arg1, Arg2, Arg3, SBFB, SBFG))
}
Return (Buffer (One)
{
0x00
})
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
If (LLess (OSYS, 0x07DC))
{
Return (SBFI)
}
If (LEqual (SDM1, Zero))
{
Return (ConcatenateResTemplate (SBFB, SBFG))
}
Return (ConcatenateResTemplate (SBFB, SBFI))
}
}
}
The important things to check here are that the device descriptor code names the I2C HID Device as "SBFB" as can be seen in the first few lines of code:-
Code:
Device (TPL0)
{
Name (HID2, Zero)
Name (SBFB, ResourceTemplate ()
If it had a name other than "SBFB" then it would be necessary to rename it to "SBFB" along with all of the associated references with-in the device descriptor code, we could have used a custom Clover ACPI patch to achieve this if required.
Additionally the CRS Method for the I2C HID Device should always Return (ConcatenateResTemplate (SBFB, SBFG)). In my case the CRS method has a number of conditional returns but it seems to work ok as is due to OSI spoofing Darwin as Windows 10), however i could ensure that it always returns the correct values by modifying the CRS Method to :-
Code:
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Return (ConcatenateResTemplate (SBFB, SBFG))
}
I think HP Spectre X360 laptop's are fairly unique in that the native DSDT does not require any major DSDT edits in order to use the I2C devices, however other brand laptops will likely require DSDT edits to the I2C Device descriptor code.
The last thing we need to check is the GPIO pin that the I2C HID device uses, this can easily be found by examining the I2C HID device in the IOACPIPlane using IOREG Explorer :-
View attachment 314052
We need to look at the first hex digit of the IOInterruptSpecifiers property which gives us the GPIO pin number that the I2C device is attached to, in my case its 0x23 .. as long as this figure is less than 0x2F then no additional edits should be required to the GPIO DSDT code.
Enabling I2C Devices in OSX/MacOS
As some of you may know, Alexandre Daoud and his team have been developing
VoodooI2C for some time now, I have tried many times in the past to get the previous versions of VoodooI2C (Versions 0.XX & 1.XX) to work but never with any success.
However recently the project has gone through a major re-write, Alex has modularised VoodooI2C to support different devices via 'Satellite' extensions to the core VoodooI2C kext and in the process optimised his code and added support for many more I2C controllers and interfaces.
I'm happy to report that VoodooI2C Version 2.X.X works OTB with the 15" 2017 HP Spectre X360 .. as previously stated I have the 4K glossy screen version that has touch and pen support. If you have the same model as me then all you need to do is perform the above DSDT edit to the CRS Method for the I2C HID Device and download the latest version of VoodooI2C from the releases page :-
https://github.com/alexandred/VoodooI2C/releases
Extract the archive and install
VoodooI2C.kext and
VoodooI2CHID.kext to /L/E.
Note: Alex's documentation for VoodooI2C suggests injecting the Kext's via Clover ... whilst this method will work you should really try to avoid injecting any Kext's via Clover unless its absolutely necessary .. Injecting Kext's will slow down the boot process and as they are loaded outside of MacOS you can not check on their status via Sys Info nor interact with them. If you do decide to inject the VoodooIC2 kexts via Clover then remove FakeSMC from /L/E as it will stop Clover injecting Kext's (by design).
Finally add the following kext patches to your Clover config.plist which will stop Apples IC2 Kext's from attaching to your I2C controller (credit CoolStar):-
Code:
<dict>
<key>Comment</key>
<string>Prevent Apple I2C kexts from attaching to I2C controllers, credit CoolStar</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<data>
SU9LaXQ=
</data>
<key>InfoPlistPatch</key>
<true/>
<key>Name</key>
<string>com.apple.driver.AppleIntelLpssI2C</string>
<key>Replace</key>
<data>
SU9LaXM=
</data>
</dict>
<dict>
<key>Comment</key>
<string>Prevent Apple I2C kexts from attaching to I2C controllers, credit CoolStar</string>
<key>Disabled</key>
<false/>
<key>Find</key>
<data>
SU9LaXQ=
</data>
<key>InfoPlistPatch</key>
<true/>
<key>Name</key>
<string>com.apple.driver.AppleIntelLpssI2CController</string>
<key>Replace</key>
<data>
SU9LaXM=
</data>
</dict>
Thats all you need to do, now reboot your laptop ... you may get the "Identify your Keyboard" Wizard on first boot after installing the kext's, just press the appropriate keys and select the keyboard type as the same when you first set up OSX. After this the Touchscreen and Pen input should now be working.
If its not working then check the OSI code in your DSDT and make sure your spoofing OSX (Darwin) as Windows 10 ... Since Windows 10 natively supports touchscreen and pen input devices its possible that some code in your DSDT that is required for I2C support may not be enabled if you spoof OSX as an earlier version of Windows. I personally recommend leaving the OSI code in the DSDT untouched and use Rehabmans
XOSI SSDT Hot patch method instead.
If it still does not work or you have a different model of HP Spectre X360 (or totally different manufactures laptop) then its very likely you will need to make further DSDT edits, please see the
VoodooI2C WiKi for more info or
Alex's Thread on VoodooI2C for guidance.
Before you start you can check to see if your I2C Interface device is currently supported by checking the
VoodooI2C's compatibility page. However it may (as in my case) not be listed yet in which case your best bet is to just dive in and give it a go and report if your successful to Alex. I've sent him my findings so hopefully the 2017 HP Spectre X360 and ELAN22CA device will be added to the compatibility page soon.
Results so far with VoodooI2C installed ...
Touchscreen seems to behave like a Touchpad with absolute cursor positioning and single tap to to click. Scrolling can be done using two fingers, the direction of scrolling follows the setting in the touchpad preference plane in system preferences.
The Windows ink pen seems to invoke a ink feature built into OSX that i did not know existed till now.
View attachment 313926 View attachment 313925
The pen seems to work very well with freehand sketch and paint apps, the pen's nib hover position and nib tap work great just as they do under Windows 10 as does the the secondary (right mouse) click button (upper most button on HP Active Pen) which is useful for invoking context menus. I am not sure if the pen's erase button (lower most button on HP Active Pen) is supported .. I need to do further testing to confirm this.
Apparently the OSX Ink feature only gets enabled if a OSX supported graphics tablet is detected so it looks like the Pen device is emulating a Graphics Tablet under OSX which kind of makes sense, I haven't tried the hand writing recognition yet, something else i did not know OSX supported until now.
Examining the TPL0 Device in the IOReg shows that VoodooI2C is supporting the touchscreen as a multitouch device :-
View attachment 313943
The ELAN 22CA controller used on the 2017 HP Spectre X360 supports 10 finger multitouch so its possible that Alex will be able to add more features to the gesture engine as he further develops VoodooI2C.
I'm still experimenting with what can and can not be done with the Touchscreen and Pen but I can confirm that both still work after sleep and wake. Having touch screen and pen input has opened up a whole lot of new possibilities in MacOS.
The biggest gain for myself is being able to use the pen for fine cursor movement and tracing in Adobe photoshop.
I have to say that both the touchscreen and pen devices are working much better than i could ever imagined considering that no Apple MacBook has either of these features built in and that VoodooI2C is still relatively young in its development.
A big
Thank You 
goes out to Alex and his team for all the hard work on VoodooI2C.
Cheers
Jay
Update: May 2018 - Confirmed working with High Sierra 10.13.5
Update: June 2018 - Alex updated VoodooI2C to version 2.0.3 which seems to resolve a small issue I would see very rarely where the touchscreens X,Y position would get offset to the actual cursor/pointer position (Possible X/Y Inversion ?)
Update July 2018 - Confirmed working with High Sierra 10.13.6 - Moved all VoodooI2C kexts from Clover Injection to /L/E and using CoolStar's Clover patches to stop Apple I2C kext's from attaching to the I2C controller ... Updated main post above to reflect this improved method of installing VoodooI2C.
