Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trekstor C13 Touchpad logging. #1

Closed
enaut opened this issue Mar 11, 2018 · 5 comments
Closed

Trekstor C13 Touchpad logging. #1

enaut opened this issue Mar 11, 2018 · 5 comments

Comments

@enaut
Copy link
Contributor

enaut commented Mar 11, 2018

Thank you for writing this guide and driver!

related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1526312

Background

Problem/why we want to log:

The Linux i2c driver does not seem to work with the touchpad of this laptop although it uses the default microsoft driver. Since we did not find the root cause of the issue we want to probe the windows driver.

what was done

The DSDT and SSDT tables have been extracted with a tool called rwanything and recompiled with iasl. There were some external definitions missing so the following refs.txt was used:

External(MDBG, MethodObj, 1)

External(_GPE.MMTB, MethodObj, 0)

External(_SB.PCI0.LPCB.H_EC.ECWT, MethodObj, 2)
External(_SB.PCI0.LPCB.H_EC.ECRD, MethodObj, 1)
External(_SB.PCI0.LPCB.H_EC.ECMD, MethodObj, 1)
External(_SB.PCI0.PEG0.PEGP.SGPO, MethodObj, 2)
External(_SB.PCI0.GFX0.DD02._BCM, MethodObj, 1)
External(_SB.PCI0.SAT0.SDSM, MethodObj, 4)
External(_GPE.VHOV, MethodObj, 3)

The Patch used for the DSDT file is:

*** C:/Users/enaut/Downloads/DSDT.dsl	Wed Mar 07 20:59:04 2018
--- C:/Users/enaut/Downloads/DSDT-mod2.dsl	Wed Mar 07 21:07:29 2018
***************
*** 18,24 ****
   *     Compiler ID      "INTL"
   *     Compiler Version 0x20120913 (538052883)
   */
! DefinitionBlock ("", "DSDT", 2, "ALASKA", "A M I ", 0x01072009)
  {
      /*
       * External declarations were imported from
--- 18,24 ----
   *     Compiler ID      "INTL"
   *     Compiler Version 0x20120913 (538052883)
   */
! DefinitionBlock ("", "DSDT", 2, "ALASKA", "A M I ", 0x01072010)
  {
      /*
       * External declarations were imported from
***************
*** 4422,4427 ****
--- 4422,4444 ----
                  {
                      Return (RBUF) /* \_SB_.PCI0.I2C2.RBUF */
                  }
+ 				
+ 				Device(SPB1)
+ 				{
+ 					Name(_HID, "DEBDEBD")
+ 					Name(_UID, 1)
+ 					Method(_CRS, 0x0, NotSerialized)
+ 					{
+ 						Name (RBUF, ResourceTemplate ()
+ 						{
+                         I2cSerialBusV2 (0x002C, ControllerInitiated, 0x000186A0,
+                             AddressingMode7Bit, "\\_SB.PCI0.I2C2",
+                             0x00, ResourceConsumer, , Exclusive,
+                             )
+ 						})
+ 						Return(RBUF)
+ 					}
+ 				}
  
                  Device (TPD0)
                  {
***************
*** 4433,4439 ****
                      Name (SBFB, ResourceTemplate ()
                      {
                          I2cSerialBusV2 (0x002C, ControllerInitiated, 0x000186A0,
!                             AddressingMode7Bit, "\\_SB.PCI0.I2C2",
                              0x00, ResourceConsumer, , Exclusive,
                              )
                      })
--- 4450,4456 ----
                      Name (SBFB, ResourceTemplate ()
                      {
                          I2cSerialBusV2 (0x002C, ControllerInitiated, 0x000186A0,
!                             AddressingMode7Bit, "\\_SB.PCI0.SPB1",
                              0x00, ResourceConsumer, , Exclusive,
                              )
                      })

Adjustments not in the instructions

Note: The name spbProbe was not working so I used DEBDEBD (conditions were: 6-7 Letters, only capitals, only hexadecimal). I don't understand the last one since there are lots of non hexadecimal names around.

Since the driver did not install to the probing device I changed the name in the drivers .inf too:

line 45: %spbProbe.DeviceDesc%=spbProbe_Device, ACPI\spbProbe
to
line 45: %spbProbe.DeviceDesc%=spbProbe_Device, ACPI\DEBDEBD

The current problem:

  1. The driver is installed and listed in Device manager->System devices with no error.
  2. The touchpad is not working and the error in the Device manager reads:
    This device cannot find enough free resources that it can use. (Code 12)
    If you want to use this device, you will need to disable one of the other devices on this system.
    
    This error is not in the HID-compatible Touchpad device but in I2C HID-Device. The original touchpad device vanished. Without the DSDT overload this device is there and occupies the resource IRQ 0x00000400 (1024)
  3. The Problem code in the I2C HID-Device driver is 0000000C
  4. The Problem status is Object Name not found. C0000034

I suspect I did something wrong with my changes of either the ASL or the drivers inf. But as I only came that far using educated guesses and pattern matching I do understand nothing of the language.

Can you help me identify the problem?

@bentiss
Copy link
Owner

bentiss commented Mar 12, 2018

First, I think the issue regarding the name ACPI\spbProbe is because I used asl.exe from Win Studio directly. I had rather developed the driver with native Windows tools to be on the safe side :)

Feel free to send a PR to change the name of the probe so it can be compatible with iasl.exe too :)

Regarding the issue you are seeing (This device cannot find enough free resources that it can use. (Code 12)), this is because you put the probe in the I2C2 scope, not in the PCI0 scope.

Either you put the probe upper in the file, in the PCI0 scope (or just open a new scope after/before the I2C2 one), or change the TPD0 reference to \\_SB.PCI0.I2C2.SPB1.

I hope I am not mistaken and this will be enough to solve the issues.

@enaut
Copy link
Contributor Author

enaut commented Mar 12, 2018

Thank you so much I actually did it. That fixed my issues I will file a PR soon.

@enaut
Copy link
Contributor Author

enaut commented Mar 12, 2018

Yep I think now everything worked as expected...
by the way I needed to use the iasl because the asl.exe failed to compile it's extracted code...

@enaut enaut closed this as completed Mar 12, 2018
@bentiss
Copy link
Owner

bentiss commented Mar 13, 2018

by the way I needed to use the iasl because the asl.exe failed to compile it's extracted code...

yes, that's the reason why I spend so much time fixing the extracted DSDT. If iasl.exe is able to recompile it's own extracted version, that's a very good news :)

@enaut
Copy link
Contributor Author

enaut commented Mar 13, 2018

well - I did not find the option to extract with iasl that's why I extracted the binary with the rw-Anything tool (GUI - I'm on windows after all ;) ) then I proceeded to decompile the extracted binary with iasl. The resulting dsdt.asl can be compiled without modification. The only problem is that I needed to list some of the external references and I also needed to provide all the SSDTs. I needed to extract those with rw-Anything too.

so summary: Its not without issues and hazzle but it's much better if you don't know the asl language...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants