Touchscreen support

[lazd]

Hardware

Touchscreen: Goodix GT9111 on 9D62 Device ID: ACPI\GDIX1001 I2C Controller: Intel Serial IO I2C Controller pci8086,9D60, pci8086,9D61, pci8086,9D62 Data sheet: GT911 datasheet (may be applicable to GT9111) Programming guide: GT911 Programming Guide

Notes:

• The I2C controller is supported by VoodooI2C
• There are Linux drivers for the Goodix 9xx
• @kernins modified the existing drivers for the GT9111 with several comments on the GT9111's behavior
• Ubuntu dmesg output and hardware list
• Reset sequence as part of DSDT on GPD Pocket 2

[lazd]

Hey @coolstar, were you working on porting this driver to macOS back in 2015? I saw you mentioned here. If you have any insight or WIP code to share, that would be appreciated!

[THEDEVIOUS1]

@lazd i see u beat me to contacting the voodoo devs which was probably a good thing since u seem to be a bit more knowledgeable about the ins & outs...if u dont mind can u send me a prebuilt copy of the driver youre working on? also...im willing to test whatever u want me to so feel free to keep in constant contact with me(wont be a bother at all) as i have been working on getting the touchscreen going as well through dsdt and bios changes

[lazd]

hey @THEDEVIOUS1, the code lives at https://github.com/lazd/VoodooI2CGoodix, and though it matches the GDX1001 device, it doesn't do anything with it at all yet.

As of now, the hurdle seems to be that we need to send a power-on sequence to the touchscreen with GPIO, and VoodooI2C doesn't seem to make public the API that is necessary to do that. I'm sure it's possible, but it may require some refactoring. Once that's possible, I can continue to port over the Linux driver code that communicates with the touchscreen over I2C. At that point, we're likely to have lots of fun bugs related to power management, suspend/resume, orientation, etc, and your testing will be super valuable.

Can you share the details of the DSDT and BIOS changes you've been working on? Given that the I2C bus seems to be working properly, and I am able to match on the device, I wonder if anything is required? That said, like my gitter message says, I am unable to read from the device over I2C, and though I assume that's because the power-on sequence hasn't been sent, perhaps it's related to the changes you're working on?

[THEDEVIOUS1]

i saw the code on your git hub already...i needed a prebuilt version because i cant/dont know how to compile apparently. sorry if thats a stupid request...have probably 20 different dsdts that range from the basic changes suggested by the voodoo guide to drastic changes deleting devices/using files from other laptops. a lil later today will triple check what i believe gave the best results i.e. the longest log and send them...i think the bios may be key as changing the touch screen preferences definitely makes a difference but if u dont mind would love to give what u got a try

[lazd]

@THEDEVIOUS1 understood. I will send you the kext, but it doesn't actually do anything except dump log statements right now -- it's all just stubbed out methods and commented out code.

What kind of results are you seeing when you change BIOS settings?

[THEDEVIOUS1]

i assume u have came to the same conclusion that they separated the touch screen(i2c2) and stylus(i2c1) into 2 different devices in the dsdt...with that said both are saying "cant get descriptor"(not exact) while the touch is saying bad bcd i believe. saw a user on gitter that had the same issue say he was able to warm boot from linux and get his touch screen to work albeit a different device with the same exact log error. in fact...mine may be working using the same hack but i lost my stylus so wouldnt know(the touch however definitely doesnt)

[lazd]

@THEDEVIOUS1 interesting. I did not come to the conclusion that touch and stylus are different, and I don't see why they would be in this case. I really don't think it's being powered on at all, and even if it was, there is no VoodooI2C satellite matching on the device ID, so it wouldn't be initialized.

With the DSDT in this repo, I'm seeing that it finds the GDIX1001 device, and adding my kernel extension on top of it, it matches and presents a multitouch interface (which of course does nothing, since the power-on sequence hasn't been sent and no attempts have been made to attach to interrupts or read data from the touchscreen).

Can you e-mail me with at the address here so I can send you the kext? Thanks!

[THEDEVIOUS1]

that was the same thing the dev alex said that he hadnt ever seen them do it that way/tthey didnt need to separate the devices in response to someone else with a weird dsdt but sure enoufgh i checked ours after reading that and realized it was basicaslly the same setup...i'll admit im a bit ignorant to all of this but there are even places to input a custom bus id and i2c address under the stylus device on i2c1 in the bios(if u hadnt seen this for yourself already). more importantly...the touch panel on i2c1 (thought to be the stylus)is in fact disabled by default if i recall correctly so that may be your main issue at the moment

[lazd]

@THEDEVIOUS1 ok, can you send along some photos of the BIOS screens where you are configuring the touch screen? I wonder if any of the options are relevant.

The I2C address bit is very interesting, as the datasheet states that you can select the slave address (0xBA/0xBB or 0x28/0x29) during power-on. So if your BIOS settings make it possible to power the touchscreen on and select the slave address at the BIOS level, then we don't need to bother with GPIO in the VoodooI2C satellite (note that I don't even know if this is possible, I'm just hypothesizing based on my limited knowledge).

[THEDEVIOUS1]

after i read the data sheet the other day i assumed the address was relevant at least but wasnt sure what format to put it ....im taking an under educated guess that its decimal since it wouldnt accept letters though. when i get finish with work i will get u both the best log screenshot and the touch panel settings( may do it in a minute actually)...think there a few other i2c elsewhere settings but not sure how much affect they have though

[THEDEVIOUS1]

ok, so...a quick data dump before i go. according to the log...your kext wont even load which make sme wonder what version macos u are using but hopefully u can make out a few of the errors in the pics i provide below(guess i couldve taken proper screen shots of he log though...smh). in fact...my system wouldnt even boot with certain settings changed. also...i forgot but i have already proven for fact that they separated the touch devices unto separate buses as stupid as it sounds because i can disable i2c2 it will kill the finger touch within windows while the pen will still work and even more interesting if i disable the i2c1 it not only kills pen in windows(but touch works) i get no display at all in mac. may be a few hours before i message back...hopefully this helps though. wait...i cant attach pics here or am i just blind?

[lazd]

You can attach screenshots, should be able to drag them in.

Very interesting that pen and touch are different. I did look at BIOS settings and tried to tell it to "Autodetect touch: enabled," of course that did nothing (Goodix isn't listed in their list of touch devices anyway).

The kext definitely loads on 10.15.2, note that if your DSDT is configured incorrectly, it will not match and therefore will not load. If you see some VoodooI2C log entries roll by that mention GDIX1001, then it's all good.

[THEDEVIOUS1]

https://drive.google.com/file/d/1H3-UMl3h5r4WcGEOggkXlJcxxGw7a_oA/view?usp=sharing we will probably have to put it on custom as auto tends to make it slect the last option in the list which a synsapsis.../in fact theres a thread from some guy that had to select custom to get his trackpad working as well

[lazd]

@THEDEVIOUS1 ah, so you're going to need to use all 3 of the kexts I provided, otherwise it won't load.

[THEDEVIOUS1]

tried that too...i was on 10.14.6 though but will try catalina later

[THEDEVIOUS1]

not sure if these will be any help but this is without using my known best dsdt but i see it exposes another couple of levels in ioreg...was just wondering, and i'll admit i may be mistaken. but i thought that when voodoo used satellite kexts that the hid one was no longer needed?

[THEDEVIOUS1]

also...note that the touch device under i2c1(stylus) and i2c2(finger) are both named TPL1 (your driver seems to only attach to the second/hand one) which may be causing confusion and i read on gitter that having multiple devices on the bus may as well...with that said if u make any adjustments to the driver please send me updated copies as u do because i have a BUNCH of testing to do with a folder full of dsdts and different bios setting combinations to try asap. one more important note i wanted to make...the above was WITHOUT gpio mode even attempted to be set and was running in polling instead which i believe i read the devs saying should work on almost all devices (but they did state gpio was better)

[THEDEVIOUS1]

i think the fix the p2 max guys had to come up with to get the touchscreen working in linux might be really relevant here although i may be mistaken...the issue was a reset sequence needed which seems to be in line with what youre saying(hopefully u havent seen this info before)

https://gpdsupport.com/t/touchscreen-issue-resolved/132

[lazd]

Oh snap @THEDEVIOUS1, I had no idea we could write the reset sequence into the DSDT... You may be onto something! Do you want to try to code up a method into the DSDT to execute the reset sequence?

[THEDEVIOUS1]

i just realized when i reread your message that it may be the same situation and did infact plan on attempting to add the dsd section later tonight(not sure why i havent tried that yet actually although i did do the low to high change suggested)...are there any changes that need to be made to the drive in anticipation of this?

[lazd]

@THEDEVIOUS1 nope, the driver should report the ID and version of the touchscreen if the reset sequence has been properly sent, AFAIK.

I don't think it's the same situation, but I do think that our edited DSDTs omit the reset sequence code completely. Adding it in could do the trick... Good luck!

[lazd]

@THEDEVIOUS1 that link you sent got me thinking, if I warm reboot from Windows, maybe the touchscreen will be on. So I tried it, and I got the following:

(VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Starting
(VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Reading version...
(kernel) VoodooI2CControllerDriver::pci8086,9d62 I2C Transaction error details
(kernel) VoodooI2CControllerDriver::pci8086,9d62 lost arbitration
(kernel) VoodooI2CControllerDriver::pci8086,9d62 I2C Transaction error: 0x07001000 - aborting
(VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Read version failed: -536870212
(VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Failed to init device
(VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Freeing

This is progress, at least it's trying to communicate over I2C and failing. If your DSDT patch works, I bet you'll get the same error as I did above.

[THEDEVIOUS1]

just to be clear...have u tried to make any of the changes suggested by the gpio pinning guide yet or are using stock dsdt and stock bios settings? dont know if u missed my other question but i know that hid kext is usually not needed with the other satellites...im getting the same results in the above screenshot(also the extra voodoo levels attached in ioreg as indicated a few messages earlier) with or without it

[lazd]

@THEDEVIOUS1 I am using the DSDT from this repo (though not the latest) and the BIOS from this repo (that enables > 4K resolution).

As far as the HID kext, you're probably right, I don't think it's needed, but it shouldn't hurt.

That output is promising, you're not getting the I2C error I am! Please share your DSDT and BIOS settings and I'll see if I can figure out why it's just dumping 0 out.

[THEDEVIOUS1]

this dsdt has a heavily edited i2c section(even removed the stylus device which possibly may be already working but as i said before i lost mine so couldnt test)....i will go back a lil later and attempt to figure out the minimum amountt of alterations needed to achieve the above log results. oh yeah...my bios settings are all default except the dvmt is set to 64 to enable 4k. also...the results seem to be the same wether warm booting from linux or windows at least at this point anyway

DSDT.aml.zip

[lazd]

@THEDEVIOUS1 thanks, with your DSDT, I get the same output after a warm boot. I will investigate whether it's actually working now.

Can you determine the GNUM for the RST and INT pins, such that we can pass them to SGOV? The actual pins on the device are RST 22, and INT 16, but I don't know how to translate those into the hex value being passed in the GPD link you sent.

[lazd]

@THEDEVIOUS1 I was unable to get more than zeros out of I2C, despite trying a different method to read from the register. Looking at the GDP P2 DSDT, it seems like we still have a long way to go in terms of defining pins and addresses.

I don't see a definition of the reset pin in our DSDT, nor do I see it setting the I2C address. I am clueless when it comes to DSDT patching, so I'll defer to you on how to get this data in and ensure it's correct. In the mean time, I will try to read up and learn more about ACPI so I can assist.

[lazd]

@THEDEVIOUS1 when you come back online, join this Gitter room so we can discuss DSDT stuff. Cheers!

[lazd]

@THEDEVIOUS1 I spent a little more time than I would like to have messing with the DSDT, comparing it to the GPD 2 Max, comparing it to original dumps, and modifying various aspects of it. Despite my efforts, I still can't get anything out of it when I try to read the version.

As far as I can tell, the one bit that's required to avoid the error when reading from I2C is:

        Name (SSCN, Package (0x03)
        {
            0x01B0, 
            0x01FB, 
            0x1E
        })
        Name (FMCN, Package (0x03)
        {
            0x48, 
            0xA0, 
            0x1E
        })

What does that do, and where did it come from? Where can I read more about it?

[lazd]

@THEDEVIOUS1 I finally have it talking to the touchscreen over I2C! My error was in the endianness of the register address (the touchscreen uses big endian, and the CPU, of course, is little endian).

kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Probing
kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Starting
kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Reading version...
kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::ID 9111, version: 2020
kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Device initialized

A warm boot, your DSDT (or this one DSDT.i2c_working.zip if yours doesn't work), and VoodooI2CGoodix-8ba8217f677b4d8042ac151bdbc84096d5815901.zip should yield the above results.

I will now try to read configuration from the device, then see if the interrupt works.

Meanwhile, can you keep working on the DSDT and try to get the reset sequenced coded into the _PS0 method? If you're successful, you'll get the ID 9111, version: 2020 on a cold boot.

[THEDEVIOUS1]

ok, so....i got the same results as u which seems to be good news but it looks like the driver is no longer attaching in ioreg although i'll admit im not sure how huge of an issue that is. actually....as far as i can tell its already working from a cold boot but i guess i need to try putting it to sleep then a power on(which breaks my brightness and power button sleep fixes). if u look at the logs u will see the sscn(standard speed?) and fmcn(fast mode) errors listed under i2c0(where i didnt add them) and are mentioned more than once by the devs as a possible fix...as far as i know its for optimal bus timing speed. please dont make the mistake that i understand most or even any of this stuff...lol. most is trial and error and a lot of copy cat & paste....with that said those values may not only be unnecessary but actually interfering with things. oh yeah...i know this is not a priority right now but can u recode the driver to work on mojave when u get chance please

[lazd]

Yes, I disabled the rest of the driver code while I was testing this, I’ll re-enable it once I get further.

Can you link to the dev’s insight on SSCN/FMCN so I can read it?

As far as Mojave, I don’t know what would need to change to make it work. Let’s table that until we actually have results on Catalina.

[THEDEVIOUS1]

[https://gitter.im/alexandred/VoodooI2C?at=5cbcbde92e2caa1aa6976be0(url) not sure how much useful info is in there & im sure it was mentioned more than once...i agree about mojave. also...could u confirm that u are getting consistent results on cold boot too when u can?

[lazd]

Thanks. Meanwhile, I am successfully reading the config from the panel.

kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Config read successfully
kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::ts->abs_x_max = 1920
kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::ts->abs_y_max = 1080
kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::ts->int_trigger_type = 1
kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::ts->max_touch_num = 10

[lazd]

It's rough and dirty, but I have working touch coordinates being reported via the interrupt handler:

kernel: (VoodooI2CGoodix) VoodooI2CGoodixTouchDriver::Touch 0 at 1889, 19 with width 80

VoodooI2CGoodix-678ac99d0804bcc4a76b77a894f32a4ecf47b553.zip

[THEDEVIOUS1]

about to give it a go now....im up for at least ther next few hours so let me know if u need anything

[THEDEVIOUS1]

only getting the message below even with all 3 kexts loaded whether i warm boot windows or cut it on cold.. .im assuming u have made additional alterations to the dsdt?

[lazd]

Odd, I think your DSDT might be messed up. Can you try DSDT.i2c_working.zip?

Also, here's a kext that makes the touchscreen sort of work like a trackpad. VoodooI2CGoodix-06dcecfa73348b6b0c75c44f944c7d342a13af86.zip

I'm still figuring out how to use the VoodooI2C multitouch API, but this is definite progress!

[THEDEVIOUS1]

i gotta give it to u....GREAT job my guy! i know its not finished yet but just to have the proof of concept and now know all of these hours spent working on this werent wasted is awesome...gonna see about switching from polling to gpio mode and a few more things things then report back asap but let me know if u need anything else tested or other additional info

[lazd]

@THEDEVIOUS1 thanks, glad to hear it's working! There are plenty of whacky bugs to be squashed I'm sure, and it definitely doesn't work the way we want it to yet, but I bet it will in short order!

I'm cleaning up the code and will go back to the Voodoo devs for insight on how to make it actually behave like a touchscreen. Then there's more cleanup to do, tons of testing, as well as support for other Goodix devices.

[THEDEVIOUS1]

not sure if having that third hid kext is hurting or helping your efforts but just to be clear...u know its not needed right? the work u have done up to this point functions exactly the same without it and as far as i have read the devs have always stressed not having it loaded when using other satellites. just throwing that out there in case it may be interfering....of course u shouldnt consider this criticism or complaining as its only for your consideration in case u havent tried the goodix driver and voodooi2c combo alone and again congratulations

[lazd]

@THEDEVIOUS1 yeah I don't think it's causing any harm, but you're right, I probably don't need to keep zipping it up.

Right now I'm struggling with the fact that the touch screen reports vertical (Y) coordinates with a value between 0 and 1920, and horizontal (X) coordinates with a value between 0 and 1080. It's not simply a case of swapping the inputs, and it has nothing to do with the fact that our screen is rotated, the touchscreen itself thinks that the Y direction has values ranging across the X scale's continuum, and visa versa. Reading the datasheets and programming guides, I can't seem to figure out how to change that.

Obviously, I can fix it by dividing the X values by the Y scale and multiplying it by the X scale, but that seems very hacky...

I wonder if it's a quirk of the way the Windows code is powering on/configuring the panel... We should test a Linux warm boot and see if reported coordinates are different. I will provide a kext shortly for you to poke at.

Meanwhile, @THEDEVIOUS1, can you join the gitter room so we can talk in real time?

[lazd]

Here's a kext with a nicely behaving "touchpad" interface using the hacky math described in my previous comment. It should be predictable, and the cursor shouldn't freeze anywhere. You can also see lots of coordinates logged to the console where the various swaps/inversions are happening to get the data correct.

VoodooI2CGoodix-9e25dd3.zip

[lazd]

@THEDEVIOUS1 I got some insight from @alexandred on how to make this behave like a touchscreen, so I will be working on that.

In the mean time, he also provided some insight about the power-on sequence, it may be possible to get it to work from a cold boot by writing the sequence into the DSDT. If you get a chance, look over what we discussed and see if you can guess the pin numbers and implement it.

[THEDEVIOUS1]

i thought maybe u may have missed some info i provided earlier...so are u saying that its confirmed NOT working from a cold boot for u? i stated earlier that as far as i can tell that it IS in fact functioning fine for me a few messages ago...can u give me the exact sequence u are using to boot where the touch screen wont work properly please? also...just joined the gitter but not sure how much help im gonna be since im not technically well versed in this stuff but hopefully there isnt much more left to figure out as far as the dsdt goes though

[lazd]

Whoa ok, you're right, it does seem to work from a cold boot, interrupts and all. I interpreted your message to mean that the I2C communication was working from a cold boot (which I confirmed), but I did not realize interrupts were also working from a cold boot.

That said, it does not seem to work after sleeping with Apple Menu -> Sleep.

[lazd]

I've released VoodooI2CGoodix 0.1.0, which enables basic touchscreen support (tap, drag, and multitouch interactions such as two-finger scrolling). There are a few bugs, so please comment on those issues if you experience the problem, and file new issues if you have a reproducible bug.

It is known working with the following DSDT, which will likely be patched further: DSDT-lazd-2020-1-6.zip.

[hatran0884]

work like a charm, cannot believe one day I will be able to use multitouch on a hackintosh. still work after sleep. thanks for such a great effort.

[kostaskas]

Gues excellent mod, works accurately without bug till now on things I use it. I tried latest 0.2.1 version with DSDT. Keep up the good work.

I will do more tests and inform you

[lazd]

@kostaskas great to hear! I imagine you're going to see some issues on sleep, and perhaps on shutdown. Please join this Gitter room so we can talk about DSDT issues.

Did you use the DSDT I included?

Did you test sleep/wake?