3 ms·

Thanks for the link to the WIP driver. Since you have a lot of experience in this area, I'm curious: 1. What's the __1e6 alignment? [0] I've never heard of t

Thanks for the link to the WIP driver. Since you have a lot of experience in this area, I'm curious: 1. What's the __1e6 alignment? [0] I've never heard of that. 2. How is the driver author going about writing that driver? Some of the comments seem to allude to analyzing what the Windows driver is doing. Do you think they're disassembling the Windows driver and trying to re-implement a Linux compatible driver in C? I don't see how anyone could implement a driver like this off the bat without some data sheet or existing code to look at. Edit: thanks to people pointing out it's __le16, not __1e6. I need to change my font; even now I can barely tell the 1 and l apart. [0] https://github.com/cb22/macbook12-spi-driver/blob/master/applespi.c#L63 https://github.com/cb22/macbook12-spi-driver/blob/master/app...

DannyBee 10y ago
it's not 1e6, it's le16 Little endian 16 bit As for the driver itself, the spi interfaces are not too hard to understand. It's unlikely anyone is disassembling anything. The normal way to figure out the packets the touchpad uses are to look at the datasheets/etc you can find on whoever made the touchpad. In this case, it's a bcm5974, and if you look at that driver, you'll see the packet format is the same. Otherwise, you write a packet dumper and start pushing things
- ndesaulniers 10y ago
  ah, there's also an interesting discussion in an GH issue. They reference the data sheets of the parts mentioned from an iFixit teardown. There's also discussion of disassembling the OSX driver. And here's info on how the author sniffed SPI traffic on Windows. [1] [0] https://github.com/cb22/macbook12-spi-driver/pull/1#issuecomment-238819981 https://github.com/cb22/macbook12-spi-driver/pull/1#issuecom... [1] https://github.com/cb22/macbook12-spi-driver/issues/3#issuecomment-248405522 https://github.com/cb22/macbook12-spi-driver/issues/3#issuec...
detaro 10y ago
1.) It is __le16 with an L, not __1e16, and it means that it is a little endian field for bitflags, the tooling makes sure it is properly handled (not mixed with numbers or fields in the wrong endianess). See this Stack Overflow post and especially the links in the accepted answer: https://stackoverflow.com/questions/9680399/what-does-typedef-u16-bitwise-le16-mean-in-linux-kernel https://stackoverflow.com/questions/9680399/what-does-typede...
leifliddy 10y ago
The author details here what he did to debug the windows spi driver: https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51 https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51
- leifliddy 10y ago
  "As an aside, for anyone interested in helping reverse engineer things: It's possible to get Windows to dump everything it sends on what it calls SPB - basically SPI & I2C. Open the Event Viewer and enable View -> Show Analytic and Debug Logs. Then head to Application and Services Logs -> Microsoft -> Windows -> SPB-ClassExtension. Right click on Analytic and enable it - all events will be logged. Disable it when done, and look for the 1023 events, and view the details tab - they'll give you the full buffer contents. Other events will let you know things like the direction of the transfer, etc."

DannyBee 10y ago

it's not 1e6, it's le16 Little endian 16 bit As for the driver itself, the spi interfaces are not too hard to understand. It's unlikely anyone is disassembling anything. The normal way to figure out the packets the touchpad uses are to look at the datasheets/etc you can find on whoever made the touchpad. In this case, it's a bcm5974, and if you look at that driver, you'll see the packet format is the same. Otherwise, you write a packet dumper and start pushing things

ndesaulniers 10y ago
ah, there's also an interesting discussion in an GH issue. They reference the data sheets of the parts mentioned from an iFixit teardown. There's also discussion of disassembling the OSX driver. And here's info on how the author sniffed SPI traffic on Windows. [1] [0] https://github.com/cb22/macbook12-spi-driver/pull/1#issuecomment-238819981 https://github.com/cb22/macbook12-spi-driver/pull/1#issuecom... [1] https://github.com/cb22/macbook12-spi-driver/issues/3#issuecomment-248405522 https://github.com/cb22/macbook12-spi-driver/issues/3#issuec...

detaro 10y ago

1.) It is __le16 with an L, not __1e16, and it means that it is a little endian field for bitflags, the tooling makes sure it is properly handled (not mixed with numbers or fields in the wrong endianess). See this Stack Overflow post and especially the links in the accepted answer: https://stackoverflow.com/questions/9680399/what-does-typedef-u16-bitwise-le16-mean-in-linux-kernel https://stackoverflow.com/questions/9680399/what-does-typede...

leifliddy 10y ago

The author details here what he did to debug the windows spi driver: https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51 https://bugzilla.kernel.org/show_bug.cgi?id=108331#c51

leifliddy 10y ago
"As an aside, for anyone interested in helping reverse engineer things: It's possible to get Windows to dump everything it sends on what it calls SPB - basically SPI & I2C. Open the Event Viewer and enable View -> Show Analytic and Debug Logs. Then head to Application and Services Logs -> Microsoft -> Windows -> SPB-ClassExtension. Right click on Analytic and enable it - all events will be logged. Disable it when done, and look for the 1023 events, and view the details tab - they'll give you the full buffer contents. Other events will let you know things like the direction of the transfer, etc."