Hi Marge,
On Thu, Aug 01, 2024 at 09:52:48AM +0000, Marge Yang wrote:
> >
> > RMI4 F12 will support to query DPM value on Touchpad.
> > When TP firmware doesn't support to report logical and physical value within the Touchpad's HID report, We can directly query the DPM value through RMI.
>
> It seems to me the logic is inverted, if there is resolution register the new code will query it directly, otherwise it will try to get it from the subpacket data. Is it intentional? Or did I parse it incorrectly?
> [Marge 08/01]
> Previously, we obtained this information by querying subpacket data. However, when the "Query DPM" feature is present, querying subpacket data may become unreliable, leading to inconsistencies in the pointing speed.
>
> This also does not appear to be tied to the HID transport but rather generic RMI4 code. Did I miss the connection?
> [Marge 08/01]
> This change applies to generic RMI4 code and is not related to HID transport.
OK, so how about this patch description then:
"Newer firmware allows to query touchpad resolution information by
reading from resolution register. Presence of resolution register
is signalled via bit 29 of the "register presence" register.
On devices that lack this resolution register we fall back to using
pitch and number of receivers data to calculate size of the sensor."
> >
> > Signed-off-by: Marge Yang <marge.yang@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Vincent Huang <Vincent.Huang@xxxxxxxxxxxxxxxx>
> > ---
> > drivers/input/rmi4/rmi_f12.c | 41
> > +++++++++++++++++++++++++++++++----------
> > 1 file changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/input/rmi4/rmi_f12.c
> > b/drivers/input/rmi4/rmi_f12.c index 7e97944..6a7a17d 100644
> > --- a/drivers/input/rmi4/rmi_f12.c
> > +++ b/drivers/input/rmi4/rmi_f12.c
> > @@ -24,6 +24,7 @@ enum rmi_f12_object_type { };
> >
> > #define F12_DATA1_BYTES_PER_OBJ 8
> > +#define RMI_QUERY_DPM_IN_PRESENSE_BIT 29
>
> Why "BIT"? Should it be called RMI_F12_RESOLUTION_REG or similar?
> [Marge 08/01]
> The "QUERY DPM" feature is the 29th bit in the F12 2D QUERY Presence register.
> By checking this bit, we can determine whether certain features are supported.
> I will rename it from "RMI_QUERY_DPM_IN_PRESENCE_BIT" to "RMI_F12_QUERY_RESOLUTION_REG".
OK, I see. I think since you are checking presence of a register either
RMI_F12_QUERY_RESOLUTION_REG or simply RMI_F12_QUERY_RESOLUTION is
better than "_BIT" variant.
>
> >
> > struct f12_data {
> > struct rmi_2d_sensor sensor;
> > @@ -73,6 +74,8 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
> > int pitch_y = 0;
> > int rx_receivers = 0;
> > int tx_receivers = 0;
> > + u16 query_dpm_addr = 0;
> > + int dpm_resolution = 0;
> >
> > item = rmi_get_register_desc_item(&f12->control_reg_desc, 8);
> > if (!item) {
> > @@ -122,18 +125,36 @@ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
> > offset += 4;
> > }
> >
> > - if (rmi_register_desc_has_subpacket(item, 3)) {
> > - rx_receivers = buf[offset];
> > - tx_receivers = buf[offset + 1];
> > - offset += 2;
> > - }
> > + // Only supports to query DPM value on RMI F12.
>
> I am unsure what this comment means... We are in F12 code, so what does "only" mean here?
> [Marge 08/01]
> The main point is to emphasize the new approach that applies when the "query DPM" feature is present.
> New comment:
> Use the Query DPM feature when the "query resolution register" exists.
Sounds good to me.
Thanks.
--
Dmitry
