4 ms·

So a part that cannot tolerate a change in data characteristics the same way that a genuine part can must be allowed to function?

arghwhat 3y ago
Rather unlikely for that to occur in a genuine scenario as neither side of the interface is software defined and as the functionality is fixed and provided by a third party.
- nomel 3y ago
  The knock off probably didn't implement something correctly, in hardware.
  - arghwhat 3y ago
    Unlikely as this is industry standard interfaces, and the "knock-off" would be made by genuine display manufacturers - possibly even one Apple uses - as you can't exactly make that in a backroom.
    - nomel 3y ago
      As someone who works in the hardware world, who has done lots of hardware interoperability testing, none of these points are correct.
      - arghwhat 3y ago
        Did you work for display panel driver manufacturers or an industry dealing with similar PHY's or are you applying assumptions about unrelated hardware from an unrelated field? If a panel driver manufacturer messed up the standard MIPI DSI and eDP interfaces for a bog standard smartphone panel, they would not have a business. Conformance is easy to validate due to the very limited scope. On the other end, Apple likely sources a third party IP block (as is standard in the industry) for their SoCs, and have little to do with over what goes on the wire. If the display was a dud for other reasons and the software update overlap was coincidental, then sure Apple is without blame - this could happen with an original screen too.
        nomel 3y ago
        Well, you’re assuming a display module only contains a display. See my original comment: > with a knock off display/touch module I don’t agree with this, > they would not have a business > Conformance is easy to validate due to the very limited scope This is difficult to respond to, since we come from such different backgrounds. Your assumption is that there is reasonable QA, for a knock off part. Even though this is a logical assumption to have, it is incorrect. QA can very often be, does it work in this device we have right here? And, implementing a hardware interface correctly doesn’t mean much when you, for example, attach a flex that makes the signal marginal.

arghwhat 3y ago

Rather unlikely for that to occur in a genuine scenario as neither side of the interface is software defined and as the functionality is fixed and provided by a third party.

nomel 3y ago
The knock off probably didn't implement something correctly, in hardware.
- arghwhat 3y ago
  Unlikely as this is industry standard interfaces, and the "knock-off" would be made by genuine display manufacturers - possibly even one Apple uses - as you can't exactly make that in a backroom.
  - nomel 3y ago
    As someone who works in the hardware world, who has done lots of hardware interoperability testing, none of these points are correct.
    - arghwhat 3y ago
      Did you work for display panel driver manufacturers or an industry dealing with similar PHY's or are you applying assumptions about unrelated hardware from an unrelated field? If a panel driver manufacturer messed up the standard MIPI DSI and eDP interfaces for a bog standard smartphone panel, they would not have a business. Conformance is easy to validate due to the very limited scope. On the other end, Apple likely sources a third party IP block (as is standard in the industry) for their SoCs, and have little to do with over what goes on the wire. If the display was a dud for other reasons and the software update overlap was coincidental, then sure Apple is without blame - this could happen with an original screen too.
      - nomel 3y ago
        Well, you’re assuming a display module only contains a display. See my original comment: > with a knock off display/touch module I don’t agree with this, > they would not have a business > Conformance is easy to validate due to the very limited scope This is difficult to respond to, since we come from such different backgrounds. Your assumption is that there is reasonable QA, for a knock off part. Even though this is a logical assumption to have, it is incorrect. QA can very often be, does it work in this device we have right here? And, implementing a hardware interface correctly doesn’t mean much when you, for example, attach a flex that makes the signal marginal.