Even if it's all-or-nothing and no generic drivers are implemented, it's better to deny new features than to cripple a working device. Apple defines the third-party market with how much documentation it releases. This is not a technical or practical problem, it's Apple not easing its iron grip, as it always does.

Would you mind pointing me to the implementation spec for the Pixel 2's touchscreen controller?

Sure, Download the source from https://source.android.com/setup/build/downloading. The driver is in kernel/drivers/input/touchscreen.

Unless the Pixel 2's touchscreen is so weird that it needs a new driver, this will work for everyone.

I looked at it, but that doesn't actually tell me the touchscreen interface. It just tells me the bits they're currently using. If Apple had open sourced their driver it wouldn't have made a difference, as whatever they're doing differently wouldn't have been in it until now. In order for me to make a fully compatible touchscreen, I need the datasheet and programming manual for the touchscreen controller.

As much as open source is a thing for software, it is not for hardware and especially silicon.

> I looked at it, but that doesn't actually tell me the touchscreen interface. It just tells me the bits they're currently using.

I have to agree with you on this. This is not a full hardware specification, it just tells how the hardware should behave up until the driver was released.

Modern open source hardware is still far in the future.

Open source hardware's still far in the future, and I'm actively worried about open silicon. The RISC-V foundation is making steps in the right direction, but it'll be a long time coming before I have a document that isn't under several layers of NDA telling me how to configure the memory controller on the latest Snapdragon.