I2C0 @ 0x00 Address 0x00 is general call address which makes Cover incompatible with standard I2C drivers.

WDSA Table

Name(ABUF, ResourceTemplate()
{
    I2CSerialBus(0, ControllerInitiated, 0x61a80, AddressingMode7Bit, "\\_SB.I2C1", 0, ResourceConsumer, , )
    GpioInt(Level, ActiveLow, Shared, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , ) {0x59}
})
Name(EBUF, ResourceTemplate()
{
    I2CSerialBus(0, ControllerInitiated, 0x61a80, AddressingMode7Bit, "\\_SB.I2C1", 0, ResourceConsumer, , )
    GpioInt(Level, ActiveLow, SharedAndWake, PullDefault, 0, "\\_SB.GPIO", 0, ResourceConsumer, , ) {0x75}
})

Address 0x00; Speed 400kHz

GPIO Interrupts: 0x59 -> L1 0x75 -> O5

From 5.1.1 HID Descriptor Format

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.

Whats wrong here?

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

Observation

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.

Maybe we have to write a kenel module which will init the tCover IC and hand off controll to I2C-HID Driver