[Trimming down the CC list a bit...]
Hi all.
On Fri, 2017-11-17 at 18:16 +0100, Luca Ceresoli wrote:
> What about all the other registers? The datasheet lists a few dozen,
> not only 0x80. Are they implemented in the panel you are working on?
>
> > The point is that datasheet seems to be official by Focaltech,
> > like if they deliver that IC with a standard FW inside.
> > I can't find a way to safely probe if it's a standard FW or from
> > EDT M09
> > or M06.
>
> Since everything is based on the programmed firmware, and there's no
> "standard" way to detect firmware version, every firmware detection
> is
> bound to be a hack. But there's no better way I'm afraid. Thus device
> tree seems the only reliable way...
>
> However, did you check registers FIRMID, FT5201ID (CTPM Vendor ID)
> and ID_G_LIB_VERSION_H/L? According to their name they might hold
> interesting info.
When I tried to read them from a solomon/goldentek display/touch I did
get unreliable data, i.e. I got different values when I had a power
cycle inbetween the startups.
Basically the firwmare did not implement these registers on the i2c
registers and I believe I got whatever happened to sit in the RAM at
that point. And that was the point where I gave up on trying to
determine the vendor and product, unless I knew where to look for it
(mainly the EDT family of touches).
And that dubiousness extended to the other registers. At some point I
had arbitrary register access via sysfs, but I did not actually bother
to determine if they had any effect or provided useful values.
Trying to communicate with representatives from Solomon Goldentek (in
this case) proved to be incredibly frustrating, because they did not
even understand what I was asking for. You don't get a datasheet
describing the actual firmware in the chip, it always is the same
focaltec datasheet that seems to consist of a lot of wishful thinking.
Sometimes you get a linux driver that might even implement a firmware
update method, but the quality of the code typically is not that great.
Fortunately the "Generic" method implemented in the patch I referred to
earlier seems to work reasonably well for the Displays I have at hand.
You can configure the max. resolution via devicetree and that gets you
95% of the way.
I would not mind additional properties in the devicetree for certain
quirks of specific devices (but encoding the vendor of the touch seems
beyond the point to me). As for frequent recalibration I am not so
sure, but then I've not yet seen a touch device where this has to be
done.
(for the records: the "M12" series from EDT is based on a different IC,
but their firmware implements a M09-style protocol with a few
additions, mainly to identify the panel.)
Bye,
Simon
--
kernel concepts GmbH Simon Budig
Sieghuetter Hauptweg 48 simon.budig@xxxxxxxxxxxxxxxxx
D-57072 Siegen +49-271-771091-17
http://www.kernelconcepts.de/
HR Siegen, HR B 9613; Geschäftsführer: Ole ReinhardtAttachment:
signature.asc
Description: This is a digitally signed message part
