Hi Dmitry,
On 06/06/2023 20:44, Dmitry Torokhov wrote:
On Tue, Jun 06, 2023 at 08:12:04PM +0200, Neil Armstrong wrote:
Hi,
On 06/06/2023 17:31, Hans de Goede wrote:
Hi Neil,
On 6/6/23 16:31, Neil Armstrong wrote:
These touchscreen ICs support SPI, I2C and I3C interface, up to
10 finger touch, stylus and gestures events.
This initial driver is derived from the Goodix goodix_ts_berlin
available at [1] and [2] and only supports the GT9916 IC
present on the Qualcomm SM8550 MTP & QRD touch panel.
The current implementation only supports BerlinD, aka GT9916.
Support for advanced features like:
- Firmware & config update
- Stylus events
- Gestures events
- Previous revisions support (BerlinA or BerlinB)
is not included in current version.
The current support will work with currently flashed firmware
and config, and bail out if firmware or config aren't flashed yet.
What I'm missing here / in the commit msg of
"input: touchscreen: add core support for Goodix Berlin Touchscreen IC"
is an explanation why this is a new driver instead of adding
support to the existing goodix.c code.
I assume you have good reasons for this, but it would be good
if you can write the reasons for this down.
Sure, should I write it down here and/or update the commit message in a new revision ?
Anyway, here's the reasons:
- globally the event handling "looks like" the current goodix.c, but again the offsets
are again different and none of the register address are the same, and unlike the current
support all registers are provided by the "ic_info" structure
- while with the current code it *could* be possible to merge it, with a lot of changes,
the firmware management looks really different, and it would be really hard to merge.
But I may be wrong, and may be misleaded by the goodix driver structure (even if it
went through a really heavy cleaning process).
Globally it seems they tried to match the "event handling" process of the previous
generations, but the firmware interface is completely different.
It is not unprecedented for drivers to share event processing and
implement several ways/generations of firmware update mechanisms.
Thanks for your reply, I'm perfectly aware of that, this is why I posted
this as RFC.
If the event handling is vaguely similar, I'm not sure it's worth refactoring the
current driver since I do not have the old and current IC datasheet nor
HW to check for current support non-regression.
What I'm sure is that not a single register address, flag or struct is even close
to the current upstream defined ones.
Neil
Thanks.
