Maximilian Luz

If you want to have multi-touch support, yes.

4.19 is a long-term-support release and we will try to maintain it on the same feature-level (meaning the same/similar patches) as the current release (5.5 at the moment).

@kitakar5525 If you want to try something: When I was looking over the DSDT of the SB1 for the button issue I found [this](https://gist.github.com/kitakar5525/7221bd545cbea68ef228ef8d9071b4d5#file-dsdt-dsl-L15917) somewhat interesting debug message. This code...

@kitakar5525 I don't think you can go any further with `acpi_call`. It looks like it's going wrong [here](https://elixir.bootlin.com/linux/v4.18.20/source/drivers/i2c/i2c-core-acpi.c#L609), due to `AttribRawBytes` (defined as protocol in the [I2C OpRegion](https://gist.github.com/kitakar5525/7221bd545cbea68ef228ef8d9071b4d5#file-dsdt-dsl-L16331) being accessed...

It might also help to find out what exactly is being given to the driver. I couldn't recognize anything, but if somebody else wants to try: Have a look at...

Sorry I can't help you more at the moment. I've still planned to find out the missing SB2 features via logging on Windows, maybe we can use the same approach...

Not much, there's currently a bit of discussion on gitter about the `SAM` device, which seems to be the embedded controller on the older surface devices (SB1, SP4, ...?), so...

Changed the title to better reflect the state of this. A small update following shortly.

Okay, so far we know that `SAM` is the "Surface Aggregator Module", which seems to be the embedded controller in charge of all of this. We know from [this](http://alex-ionescu.com/publications/Recon/recon2017.pdf) (thanks...

Here's the HID-over-I2C specification in a _readable_ format (because of course Microsoft needs to push their .docx format): [hid-over-i2c-protocol-spec-v1-0.pdf](https://github.com/jakeday/linux-surface/files/2990388/hid-over-i2c-protocol-spec-v1-0.pdf)