I “may” have discovered why the Goodix touch screen driver isn’t working under Windows 7.
This is all new information to me… so I could be wrong.
The device drivers under Windows 10 and Windows 8.1 that work and make the touch screen work, all refer to ACPI\GDIX1002
That means the touchscreen is an FO or PDO described by the BIOS ACPI table which is handed off to the operating system after boot.
The Plug n Play system of windows then “sees” this object in the device tree and searches for a WDM driver with a “name” that says ACPI\GDIX1002 and loads it, and that provides the service to the pen and touch subsystem built into windows.
Currently… Windows 7 is not enumerating or creating an FO or PDO for the touch screen device. It is for “other things” like the Intel HID Event filter… but that is not the touch screen.
From other posts in this forum, it seems the earlier BIOS for the GPD P2 Max had some problems with the ACPI DSDT description tables for devices attached to the motherboard… they were gradually improved.
The specification for the ACPI DSDT tables is very poor… or not well defined or explained… when Microsoft wrote their ACPI intepreter… they kept accommodating, worse and worse DSDT tables found in the wild… so the Windows 8.1 and Windows 10 interpreters could handle worse and worse DSDT tables and make things work. (well… maybe not worse… but more dialects… or personal “interpretations” of what the ACPI DSDT specification meant…)
Meanwhile it looks like GPD was improving their DSDT… until they stopped releasing firmware updates for the BIOS.
Currently I am running GPD P2 Max BIOS 0.28
There is another newer version called BIOS 0.29 which I have not applied.
In theory one of the fixes in the newer BIOS could be a better ACPI DSDT which describes the touch screen “better” so that Windows 7 would enumerate it… and subsequently load the device driver for it.
Under Linux they can “patch” the DSDT and make things work… even if they don’t have the source code… we can’t really do that in Windows because everything is signed and locked down to prevent the infiltration of malware by an unsigned driver.
Its a long shot… but it seems a possibility… I just don’t have the time to try at the moment… I have to get some sleep and go to work in the morning.
A Second way to load the Goodix device driver… as a service… might be to make it look like a null device driver… or a modem… just to get the “service” that is the code for the goodixtouchscreen.sys running. Some people have alluded to the ACPID DSDT table in earlier BIOS versions as being “meaningless” and of no real worth when running the device driver… that is a reference to the DSDT tables can not only describe a device, but also provide code for interacting with them… some device drivers then built up a “whole” device driver by using bits of code passed to the operating system from the BIOS after boot… but that doesn’t appear to be the case here… it seems Goodix included everything to run the touch screen in the runtime WDM functional device driver… or so the gossip says.
If so… then the problem with manually loading the device driver attached to a “fake” or “wrong” device… just to get the code loaded is it will deliver a “Code 10” device driver stop if it doesn’t get an expected acknowledgement after start up.
With a null or modem driver… loaded with the “wrong device driver” there isn’t such an expectation… it happily says “loaded” and starts the device driver service.
That’s pretty hackneyed … but it might be a way of getting Windows 7 to work with the touch screen… even if the ACPI DSDT can’t be fixed.
I “think” a wicked INF file could trick the system into installing and starting the “signed” goodixtouchscreen.sys device driver… it should produce a Red warning box about the INF file not being signed… but that could be overriden just for install… after its in place… the device driver itself… should be signed and owrk as design… in theory.