[TouchPad] Intel I2C driver (Serial IO) FeatureScore+Signing

Important Drivers Other Drivers
1

@Fernando l ask for your help to add a FeatureScore value of “00”+Signing to the I2C driver (iaioi2c.inf) inside this package:

64bit: https://downloadcenter.intel.com/download/26693
32bit: https://downloadcenter.intel.com/download/25475
(DriverVer=08/18/2015,1.1.1.1004)

Is the last version for the Intel I2C devices with HwID:
ACPI\VEN_8086&DEV_0F41

iaioi2c.inf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
[i2c_Device_0502.NT]
CopyFiles=Drivers_Dir
FeatureScore=00
Reboot
 
[i2c_Device_0503.NT]
CopyFiles=Drivers_Dir
FeatureScore=00
Reboot
 
[i2c_Device_0504.NT]
CopyFiles=Drivers_Dir
FeatureScore=00
Reboot
 
[i2c_Device_0505.NT]
CopyFiles=Drivers_Dir
FeatureScore=00
Reboot
 
The reason is because it can be replaced with a NULL driver from an Intel Chipset driver, indeed is a stupid implementation by Intel. NULL drivers (nonexistent) are assigned to Devices Not Used on a machine (do not typically exist) and that should not be started. Seems to be that the manufacturers use it to remove the unused devices from the Unknown Devices section of the Device manager and show information from them without installing a functional driver:
https://docs.microsoft.com/en-us/windows...g-a-null-driver

Almost all Intel ValleyView2System.inf CHIPSET drivers install a NULL driver and the 2 other nothing for this CoincidentDeviceID=ACPI\VEN_8086&DEV_0F41:
1
2
3
4
5
6
7
8
9
10
 
i2cNULLdriver?:   Version:	  Date:
YES               10.1.1.7        2015-0616
YES               10.1.1.8        2015-0626
NO                10.1.1.13       2015-1028	(Installed by WinUpdate)
NO                10.1.1.18       2016-0404
YES               10.1.1.40       2017-0103
YES               10.1.1.42       1970-0101
YES               10.1.1.44       2017-1111	(has another version with 1968-0718)
YES               10.1.1.45       1968-0718
YES               10.1.3.1        1968-0718
 
Is interesting to see how Intel note this behavior and change the date of the last Chipset drivers to 1968 for any I2C driver put itself in front, the situation is that windows rank better the newer dates making the Chipset driver version 10.1.1.44 with date 2017-1111 always the top choice.

Since the last version of the functional Intel I2C controller driver (linked above) has a date of:
DriverVer=08/18/2015
Can be replaced by any Chipset's NULL driver with a newer date than it, making unusable the TouchPad of the laptop in advanced mode (Established in BIOS). Sure its posible to install an older Chipset driver but it feel like in any moment for watever reason can be installed a newer one:

I2CvsChipset.png



So Fernando I ask you for help to add the value to make the I2C controller always the top choice no matter what. I hope you can do it and thank you in advance.

PD:
The I2C device is the only one device, other than the chipset devices, that is configured inside the ValleyView2 Chipset driver. No other devices are configured by it, not the GPIO, MBI, USB3, etc.

And this problem seems to be the cause for many complains in the web for NOT working TouchPads and TouchScreens.

PD2:
Off course the Chipset driver install functional drivers too for certain devices in a mode that I think is called RAW mode, that do not need a .SYS file from the manufacturer and that seems to interact directly with the Windows HAL or the Inbox drivers.

2

@Jodec :
Thanks for your interesting report and your idea about how to solve your specific Serial I/O driver problem.
As soon as I have the required time, I will modify the related Intel I/O driver, give it a Win-RAID CA signature and send you the link via PM.
If it should work for your specific system, I will try to enhance the compatibilty by adding other HardwareIDs.
By the way - since there is already another thread about a rather similar problem (look >here<), it may be a good idea to merge both threads and to give it a new title like “[Problem] Intel I2C Controller (Serial I/O) not working with some Touchpads”.
What do you think about it?

3

Thank you Fernando! It worked perfectly like expected, now both drivers coexist without any problem:

I2C-CHIPSET_togheter.png



I will finally sleep well at night without the fear that any automatic update can replace the I2C controller driver with a NULL driver. So thank you very much!


And I do not think will be a good idea to merge both threads since the other that you linked seems to be other problem, but it is at you merge it or not, of course. Whatever the case may be, I will read the other thread to try to help.

By the way, sorry for the delay in my posts always, is realy dificult to me write in pseudo english.