tCover Linux support
Last updated
Last updated
I2C0 @ 0x00 Address 0x00 is general call address which makes Cover incompatible with standard I2C drivers.
Address 0x00; Speed 400kHz
GPIO Interrupts: 0x59 -> L1 0x75 -> O5
From 5.1.1 HID Descriptor Format
Offset | Field | Size | Actual Value | Comment |
0 | wHIDDescLength | 2 | 00 1E | Dec: 30 -> 30 Bytes read |
2 | bcdVersion | 2 | 01 00 | Version 1.00 |
4 | wReportDescLength | 2 | 00 00 | x |
6 | wReportDescRegister | 2 | 00 42 | maybe |
8 | wInputRegister | 2 | 00 43 | maybe |
10 | wMaxInputLength | 2 | 00 00 | x |
12 | wOutputRegister | 2 | 00 44 | maybe |
14 | wMaxOutputLength | 2 | 00 00 | x |
16 | wCommandRegister | 2 | 00 45 | maybe |
18 | wDataRegister | 2 | 00 46 | maybe |
20 | wVendorID | 2 | 00 00 | x |
22 | wProuctID | 2 | 00 00 | x |
24 | wVersionID | 2 | 00 00 | x |
26 | RESERVED | 4 | 00 00 00 00 |
All important information is set to 0x00. I guess standard I2C HID Driver will have a hard time.
HID Descriptor Address is 0x41. This makes all the Register fields seem legit.
It was tested without tCover. Connecting a tCover doesn't change anything.
This should be related to wrong power settings.
Surface RT2 turns on backlight on TypeCover2 when the kernel is booted from UEFI with ACPI.
ACPI does something right according to power settings. Now we need to capture the new HID Descriptor for UEFI boot on Surface RT. Results should show what to do next
Booting Windows without tCover: Windows doesn't send a single byte to tCover. Booting Windows with tCover: Windows does send some non HID bytes before the HID Descriptor is read.
That leads to the conclusion that the SoC has a GPIO which acts as tCover detector.