Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sun, 17 May 2020 21:05:32 -0700
From:   Dmitry Torokhov <dmitry.torokhov@gmail.com>
To:     =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= <mirq-linux@rere.qmqm.pl>
Cc:     David Heidelberg <david@ixit.cz>,
        Dmitry Osipenko <digetx@gmail.com>,
        Henrik Rydberg <rydberg@bitmath.org>,
        James Chen <james.chen@emc.com.tw>,
        Johnny Chuang <johnny.chuang@emc.com.tw>,
        Rob Herring <robh+dt@kernel.org>,
        Scott Liu <scott.liu@emc.com.tw>, linux-input@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 07/10] input: elants: support 0x66 reply opcode for
 reporting touches
Message-ID: <20200518040532.GP89269@dtor-ws>
References: <cover.1587923061.git.mirq-linux@rere.qmqm.pl>
 <02dc25c5851e50d77bc707a2e1b44caf9d6354eb.1587923061.git.mirq-linux@rere.qmqm.pl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <02dc25c5851e50d77bc707a2e1b44caf9d6354eb.1587923061.git.mirq-linux@rere.qmqm.pl>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sun, Apr 26, 2020 at 07:47:52PM +0200, Michał Mirosław wrote:
> From: Dmitry Osipenko <digetx@gmail.com>
> 
> eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
> reporting touch events: one is 0x63 (used by older firmware) and other is
> 0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
> eKTH3500, while 0x63 needs small adjustment of the touch pressure value.
> 
> Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
> reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
> use 0x63.
> 
> Note: CMD_HEADER_REK is used for replying to calibration requests, it has
> the same 0x66 opcode number which eKTF3624 uses for reporting touches.
> The calibration replies are handled separately from the the rest of the
> commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
> and thus this change shouldn't change the old behavior.

Is it possible to know what format a device will use by querying it at
probe time?

Thanks.

-- 
Dmitry