Contribute
Register

HP Spectre X360 (15" 2017) - I2C Touchscreen and Pen Working in OSX

Status
Not open for further replies.

jaymonkey

Moderator
Joined
Aug 27, 2011
Messages
4,075
Motherboard
GB Z490 Vision D
CPU
i9-10850K OC @ 5.2 GHz
Graphics
RX6800-XT+UHD630
Mac
  1. MacBook Air
  2. MacBook Pro
  3. Mac Pro
Mobile Phone
  1. iOS
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 :-
Screen Shot 2018-02-18 at 12.04.26.png
We can further examine the I2C HID Controller and attached devices using Windows device manager:-

I2C-HID.PNG PEN-HID.PNG

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))
            }
        }
    }

From this code dump we now know the following :-

SBFB = I2C bus declaration which must always be returned (For either APIC/GPIO/polling).
SBFI = APIC pin
SBFG = GPIO pin

This makes it relatively easy to work with as both the APIC and GPIO pins are defined.

The important things to check here are that the I2C bus declaration is "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 the I2C bus declaration and the GPIO pin number. In my case the DSDT code is Return (ConcatenateResTemplate (SBFB, SBFG)).

in my DSDT 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 pin that the I2C HID device uses, this can easily be found by examining the I2C HID device in the IOACPIPlane using IOREG Explorer :-
Screen Shot 2018-02-18 at 13.32.38.png
We need to look at the first hex digit of the IOInterruptSpecifiers property which gives us the 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 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.
Screen Shot 2018-02-17 at 18.28.32.png Screen Shot 2018-02-17 at 18.26.34.png
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 :-
Screen Shot 2018-02-17 at 19.09.00.png
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 :thumbup::thumbup: 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.

Update November 2018 - Confirmed working with Mojave 10.14.X using updated VoodooIC2 kexts, however there is a slight issue in that scrolling using the touchscreen now requires three fingers instead of two, hopefully this will be addressed in a future update.

Update April 2019: VoodooI2C version 2.1.5 officially released which fixes the three finger scroll issue.

Update July 2019: VoodooI2C version 2.2 seems to fix the cursor offset issue I had when using the screen rotated 180 or 90 degrees, :thumbup: to the VoodooI2C dev team.
 
Last edited:
Post #2 held for further info ...
 
Is your touch screen usb?
 
Mine is elan usb and gets recognized by voodooi2c
 
Hi All,

As i've previously written in a number of other threads i've been investigating if it was possible to use the Touchscreen and Windows Ink Pen as input devices under OSX on my HP Spectre X360 (Currently running OSX 10.12.6) .. Please note that my laptop is the 15" 2017 Kaby Lake model with the 4K screen. HP Model number is 15-bl001na.

As some of you may know, Alexandre Daoud and his team of developers has been working on VoodooI2C for some time now, I 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 streamlined and optimised his code and added support for many more I2C controllers and interfaces.

I'm happy to report that the latest version of VoodooI2C (Version 2.0.1) works OTB with the 15" 2017 HP Spectre X360 .. My system has the 4K glossy screen that has touch and pen support. If you have the 13" model or a earlier or later 15" model then it may not work OTB and you may need to make some DSDT edits.

If you have the same model as me then all you need to do is download the latest version of VoodooI2C from the releases page :-

https://github.com/alexandred/VoodooI2C/releases

Extract the archive and copy VoodooI2C.kext and VoodooI2CHID.kext to clovers injected kext folder usually :-

/EFI/Clover/kexts/10.XX (or Other)

Do not (like me) install them in /S/L/E or /L/E as it wont work, the VoodooI2C kexts have to be injected early in the OSX boot process by Clover.

Thats all you need to do, reboot your laptop ... you may get the Identify your Keyboard Wizard on first boot, just press the appreciate keys and select the Keyboard type as normal. After that the Touchscreen and Pen input should be working.

If things are not working for you then check your OSI DSDT edit (i'm using Windows 10 OS spoof) ... I recommend leaving OSI in the DSDT untouched and use Rehabmans XOSI SSDT Hot patch which is what i'm using for Windows/Darwin OS spoofing.

If it still does not work or you have a different HP Spectre X360 then its likely you will need to make some DSDT edits, please see the VoodooI2C WiKi for more info, if you still have problems then use his Gitter support page but have some debug files ready to upload as detailed in his trouble shooting page.

When i first started testing VoodooI2C V2.0.1 i did make several DSDT changes as outlined in the WiKi, however after testing and consulting with Alex it became apparent that in the case of the 2017 15" Spectre X360 no changes are necessary .. this will almost certainly not be the case for everyone.

Results so far with VoodooI2C installed ...


At the moment the Touchscreen seems to emulate a Touchpad, both in cursor positioning and a single tap to to click. Scrolling can be done using two fingers, as the touchpad on the 2017 Spectre X360 is a Synaptics PS2 device I am using ReHabMans VoodooPS2Controller kext .. its possible that the two finger screen scroll is being handled by this as you can change the direction of two finger scrolling using the touchpad preference plane in system preferences...I need to do some more testing to confirm if this is the case or not.

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 however the two buttons on the pen do not work as I think they need a bluetooth client to process the button presses which under Windows is done by the HP Pen Driver. However the pen's nib hover position and nib tap work great just as they do under Windows 10.

Apparently the OSX Ink feature only gets enabled if a OSX supported graphics tablet is connected 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 ..

Examining the TPL0 Device in the IOReg shows that VoodooI2C is supporting the touchscreen as a multitouch device :-
View attachment 313943
Hopefully Alex will add more features to his 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 Sierra.

Finally, 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 and constantly evolving. I will continue to update this post with further findings as i explore the Touchscreen and Pen functionality under OSX.

Just thought i's share this finding with fellow HP Spectre X360 Owners ... hopefully others will have similar success.

A big Thank You :thumbup::thumbup: goes out to Alex and his team for all the hard work on VoodooI2C.

Cheers
Jay


Hi Jay, I wrote the touchscreen portion of the driver. Are you saying that the touchscreen behaves like a giant touchpad? If so, that’s not the intended behavior. Single touch input should be same as windows with absolute positioning of the cursor. It’s possible your transducer situation is a new one we haven’t accounted for yet.
 
Last edited:
Hi Jay, I wrote the touchscreen portion of the driver. Are you saying that the touchscreen behaves like a giant touchpad? If so, that’s not the intended behavior. Single touch input should be same as windows with absolute positioning of the cursor. It’s possible your transducer situation is a new one we haven’t accounted for yet.
The behaviour is as intended. The user just expects it to act like how a touchscreen on windows would (i.e with one finger scrolling). Such behaviour is not possible on OSX.
 
Hi Jay, I wrote the touchscreen portion of the driver. Are you saying that the touchscreen behaves like a giant touchpad? If so, that’s not the intended behavior. Single touch input should be same as windows with absolute positioning of the cursor. It’s possible your transducer situation is a new one we haven’t accounted for yet.

The behaviour is as intended. The user just expects it to act like how a touchscreen on windows would (i.e with one finger scrolling). Such behaviour is not possible on OSX.

Hi Guys,

The touchscreen does seem to work pretty much like how the touchpad works or at least it does in my case, i can use absolute cursor positioning using a single finger, and single finger tap to select. Screen/Page scrolling requires two fingers ... which makes sense to me as (like Alex says) OSX does not support single finger scrolling.

Was not sure if this was a direct feature of the VoodooI2C gesture engine or because i'm using Rehabmans VoodooPS2Controller kext to support my touch pad ?

Really great work guys on VoodooI2C, have been using the pen for design work this morning and its added a whole new level to working in OSX, have been updating the first post with some findings just to help others who might be interested.

Of course at the moment its still not possible to use the laptop in tablet mode (with the keyboard folded over) as the keyboard remains active so if i rest it on my lap in tablet mode it goes bonkers with random key presses.

However I can rotate the screen 180 degrees using display preferences and put the laptop in tent mode, i could also use the OSX on screen keyboard via the menu icon ... all of which would work very well with the pen except that the touchscreen (and pens) X,Y coordinates also need rotating so not usable at the moment.

I am going to look at the HP wireless button driver which i think is how the two buttons on the pen work with windows ... should be possible to write a simple driver for OSX so that i can get secondary input clicks from the pen if i can figure out what protocol the pen and driver are using.

Are there any plans to support accelerometers and screen position sensors in VoodooI2C so that we could have support for automatic screen rotation and keyboard disable ? ... i don't think it would require too much work as the features are already in OSX so its just a case of actioning screen rotation and keyboard disable based on I2C sensor data. Would be happy to look into that if there is a existing hook for I2C sensor data already in VoodooI2C ?

Cheers
Jay
 
Last edited:
Hi Guys,

The touchscreen does seem to work pretty much like how the touchpad works or at least it does in my case, i can use absolute cursor positioning using a single finger, and single finger tap to select. Screen/Page scrolling requires two fingers ... which makes sense to me as (like Alex says) OSX does not support single finger scrolling.
Jay

Absolute positioning isn't how a trackpad works. A trackpad works by relative positioning. E.g if your place your finger in the top left corner of your trackpad, it doesn't place the cursor in the top left of the screen.

Are there any plans to support accelerometers and screen position sensors in VoodooI2C so that we could have support for automatic screen rotation and keyboard disable ? ... i don't think it would require too much work as the features are already in OSX so its just a case of actioning screen rotation and keyboard disable based on I2C sensor data. Would be happy to look into that if there is a existing hook for I2C sensor data already in VoodooI2C
Jay

Basic rotation support with I2C HID sensors already exists with VoodooI2C. It has yet to be released with a new version, however, since I have only been able to test it on my own device. You are free to come on the Gitter chat and request a beta kext of it if you indeed have I2C HID sensors (note that most SKL+ machines don't have I2C HID sensors as far as I'm aware).
 
Status
Not open for further replies.
Back
Top