Maximilian Luz

The problem is not in the kernel-userspace API, it's on the charging-controller/EC/hardware side (so basically the other side of the kernel). We need something that we can tell to actually...

A dmesg log might show something, e.g. if it's actually going to sleep or if there are any obvious issues.

The `surface_serial_hub` line you're seeing is essentially just a warning that the driver is receiving some event message from the EC that it doesn't know what to do with (meaning...

Oh, very nice work! Regarding debug logs: How are they sent to the host? Standard events? I think it would be nice if we could provide some way to enable...

Regarding terminology: I think SurfLink is the charging/dock connector. Blade (at least on the SPX) is the keyboard connector, which also uses a UART. I don't know the specifics of...

> Then you'll start seeing "dropping unexpected command message" errors in dmesg. Ah, I think that's what I meant with "events" (messages sent by the EC that are not a...

> > Then you'll start seeing "dropping unexpected command message" errors in dmesg. > > Ah, I think that's what I meant with "events" (messages sent by the EC that...

So CID=0x48 seems to send some null-terminated strings, but the majority of data seems to be in some binary format. Also my guess is that there's some timestamp and other...

> So my guess would be that all the type covers use the "Blade" protocol, and they've just changed where/how the translation to HID takes place. I think that makes...

And you are absolutely correct with the request IDs on the newer devices... they're all over the place. With the new format it looks like ``` [header] 80 07 03...