From: Caleb Connolly <caleb.connolly@linaro.org>
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.
Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Documentation/devicetree/bindings/input/syna,rmi4.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
index b522c8d3ce0db719ff379f2fefbdca79e73d027c..a80ec0c052cb1b7278f0832dd18ebd3256bc0874 100644
--- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml
+++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml
@@ -49,6 +49,24 @@ properties:
description:
Delay to wait after powering on the device.
+ syna,pdt-fallback-desc:
+ $ref: /schemas/types.yaml#/definitions/uint8-matrix
+ description:
+ This property provides fallback values for certain register fields that
+ are missing on devices using third-party replacement displays.
+ These unofficial displays contain touch controllers that claim RMI4
+ compliance but fail to populate the function_number and function_version
+ registers of their Page Descriptor Table (PDT) entries.
+
+ Since the number of required fallback entries depends on the number of
+ Page Descriptor Tables supported by a given device, this property
+ should be provided on a best-effort basis.
+
+ items:
+ items:
+ - description: The 5th byte of the PDT entry (function number)
+ - description: The 4th byte of the PDT entry (version value)
+
vdd-supply: true
vio-supply: true
--
2.47.2On Sat, Mar 08, 2025 at 03:08:37PM +0100, David Heidelberg wrote: > From: Caleb Connolly <caleb.connolly@linaro.org> > > 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? > > Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> > Signed-off-by: David Heidelberg <david@ixit.cz> > --- > Documentation/devicetree/bindings/input/syna,rmi4.yaml | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml > index b522c8d3ce0db719ff379f2fefbdca79e73d027c..a80ec0c052cb1b7278f0832dd18ebd3256bc0874 100644 > --- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml > +++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml > @@ -49,6 +49,24 @@ properties: > description: > Delay to wait after powering on the device. > > + syna,pdt-fallback-desc: > + $ref: /schemas/types.yaml#/definitions/uint8-matrix > + description: > + This property provides fallback values for certain register fields that > + are missing on devices using third-party replacement displays. > + These unofficial displays contain touch controllers that claim RMI4 > + compliance but fail to populate the function_number and function_version > + registers of their Page Descriptor Table (PDT) entries. > + > + Since the number of required fallback entries depends on the number of > + Page Descriptor Tables supported by a given device, this property > + should be provided on a best-effort basis. > + > + items: min/maxItems here > + items: > + - description: The 5th byte of the PDT entry (function number) > + - description: The 4th byte of the PDT entry (version value) Best regards, Krzysztof
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@linaro.org> >> >> 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. Some of them can be detected at runtime which is what this patchset tries to do. > >> >> Signed-off-by: Caleb Connolly <caleb.connolly@linaro.org> >> Signed-off-by: David Heidelberg <david@ixit.cz> >> --- >> Documentation/devicetree/bindings/input/syna,rmi4.yaml | 18 ++++++++++++++++++ >> 1 file changed, 18 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/input/syna,rmi4.yaml b/Documentation/devicetree/bindings/input/syna,rmi4.yaml >> index b522c8d3ce0db719ff379f2fefbdca79e73d027c..a80ec0c052cb1b7278f0832dd18ebd3256bc0874 100644 >> --- a/Documentation/devicetree/bindings/input/syna,rmi4.yaml >> +++ b/Documentation/devicetree/bindings/input/syna,rmi4.yaml >> @@ -49,6 +49,24 @@ properties: >> description: >> Delay to wait after powering on the device. >> >> + syna,pdt-fallback-desc: >> + $ref: /schemas/types.yaml#/definitions/uint8-matrix >> + description: >> + This property provides fallback values for certain register fields that >> + are missing on devices using third-party replacement displays. >> + These unofficial displays contain touch controllers that claim RMI4 >> + compliance but fail to populate the function_number and function_version >> + registers of their Page Descriptor Table (PDT) entries. >> + >> + Since the number of required fallback entries depends on the number of >> + Page Descriptor Tables supported by a given device, this property >> + should be provided on a best-effort basis. >> + >> + items: > > min/maxItems here There is no hardcoded limit how many of these items will be provided, should I put there some huge range as 1..1024? Thank you David > >> + items: >> + - description: The 5th byte of the PDT entry (function number) >> + - description: The 4th byte of the PDT entry (version value) > > Best regards, > Krzysztof > -- David Heidelberg
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@linaro.org> >>> >>> 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? Best regards, Krzysztof
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@linaro.org> >>>> >>>> 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. The third party chips were designed to work with a specific downstream driver which doesn't implement the self-describing features of RMI4 and just hardcoded the functionality they expect. Kind regards, > > Best regards, > Krzysztof -- Caleb (they/them)
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@linaro.org> >>>>> >>>>> 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. Best regards, Krzysztof
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@linaro.org> >>>>>> >>>>>> 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 -- Caleb (they/them)
On 26/03/2025 11:26, Caleb Connolly wrote: > > > 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@linaro.org> >>>>>>> >>>>>>> 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. Agree, preparing it for v4. So far proposing `compatible = "syna,rmi4-s3706b-i2c", "syna,rmi4-i2c"` (as S3706B is written in the commit and search confirms it for OP6/6T). David> >> >> Best regards, >> Krzysztof > -- David Heidelberg
On 3/28/25 23:45, David Heidelberg wrote: > On 26/03/2025 11:26, Caleb Connolly wrote: >> >> >> 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@linaro.org> >>>>>>>> >>>>>>>> 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. > > Agree, preparing it for v4. So far proposing `compatible = "syna,rmi4- > s3706b-i2c", "syna,rmi4-i2c"` (as S3706B is written in the commit and > search confirms it for OP6/6T). ack, sounds good! > > David> >>> >>> Best regards, >>> Krzysztof >> > -- Caleb (they/them)
© 2016 - 2026 Red Hat, Inc.