3 ms·

It's neither easy nor cheap. The engineer in question now has to support multiple variants of the driver, and QA has to acquire several of these screens and mai

by axoltl 9y ago

It's neither easy nor cheap. 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. I'm a little amazed by how many people in this thread don't understand how much work developing for, testing, and maintaining actual physical devices is.

ASalazarMX 9y ago
> 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.
- axoltl 9y ago
  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.
  - ASalazarMX 9y ago
    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.
    - axoltl 9y ago
      Would you mind pointing me to the implementation spec for the Pixel 2's touchscreen controller?
      - ASalazarMX 9y ago
        Sure, Download the source from https://source.android.com/setup/build/downloading 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.
        axoltl 9y ago
        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.
        ASalazarMX 9y ago
        > 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.
        axoltl 9y ago
        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.
pfortuny 9y ago
You have a working device and then you modify the software and it stops working. If it works, why change it?

by axoltl 9y ago

ASalazarMX 9y ago

> 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.

axoltl 9y ago
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.
- ASalazarMX 9y ago
  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.
  - axoltl 9y ago
    Would you mind pointing me to the implementation spec for the Pixel 2's touchscreen controller?
    - ASalazarMX 9y ago
      Sure, Download the source from https://source.android.com/setup/build/downloading 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.
      - axoltl 9y ago
        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.
        ASalazarMX 9y ago
        > 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.
        axoltl 9y ago
        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.

pfortuny 9y ago

You have a working device and then you modify the software and it stops working. If it works, why change it?