> The engineer in question now has to support multiple variants of the driver, and QA has to acquire several of these screens and maintain a dedicated test rack of them.

Conversely, the update just needs to reliably detect if the screen is Apple brand, and abort the update if it's not. If this can be done, then the current driver could be considered generic and working everywhere, and the engineer would just need to maintain the generic and the current version.

That is, if Apple didn't mind to pay for making easier for third parties to get sales instead of Apple. Somehow I don't think that's the case.

The update is an all-or-nothing type of deal though. You either update the entire system or you don't. So now people with a third-party screen don't get new features and - more importantly - they don't get security fixes.

If the update wasn't all-or-nothing, now you have to test interoperability between this generic driver and the rest of the system. That might be OK if it was just this one driver, but what if you suddenly have a generic driver for N subsystems? The combinatorics explode quite quickly.

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.

You have a working device and then you modify the software and it stops working.

If it works, why change it?