On 3/26/25 07:57, Krzysztof Kozlowski wrote:
On 25/03/2025 14:23, Caleb Connolly wrote:
On 3/25/25 08:36, Krzysztof Kozlowski wrote:
On 24/03/2025 19:00, David Heidelberg wrote:
On 10/03/2025 10:45, Krzysztof Kozlowski wrote:
On Sat, Mar 08, 2025 at 03:08:37PM +0100, David Heidelberg wrote:
From: Caleb Connolly <caleb.connolly@xxxxxxxxxx>
This new property allows devices to specify some register values which
are missing on units with third party replacement displays. These
displays use unofficial touch ICs which only implement a subset of the
RMI4 specification.
These are different ICs, so they have their own compatibles. Why this
cannot be deduced from the compatible?
Yes, but these identify as the originals.
It does not matter how they identify. You have the compatible for them.
If you cannot add compatible for them, how can you add dedicated
property for them?
Hi Krzysztof,
There are an unknown number of knock-off RMI4 chips which are sold in
cheap replacement display panels from multiple vendors. We suspect
there's more than one implementation.
A new compatible string wouldn't help us, since we use the same DTB on
fully original hardware as on hardware with replacement parts.
The proposed new property describes configuration registers which are
present on original RMI4 chips but missing on the third party ones, the
contents of the registers is static.
So you want to add redundant information for existing compatible, while
claiming you cannot deduce it from that existing compatible... Well,
no.. you cannot be sure that only chosen boards will have touchscreens
replaced, thus you will have to add this property to every board using
this compatible making it equal to the compatible and we are back at my
original comment. This is deducible from the compatible. If not the new
one, then from old one.
hmm I see, so instead we should add a compatible for the specific variant (S3320 or something) of RMI4 in this device and handle this in the driver? I think that makes sense.
Best regards,
Krzysztof