From: Gregor Riepl <onitake@gmail.com>
To: Robert Dolca <robert.dolca@gmail.com>
Cc: linux-input@vger.kernel.org
Subject: Re: [PATCH] Add generic driver for Silead tochscreens
Date: Mon, 13 Jul 2015 17:18:50 +0200 [thread overview]
Message-ID: <55A3D6DA.9090206@gmail.com> (raw)
In-Reply-To: <CAFPB+YcZnzHVdztqYuD63fNGhedDZR4xEW8Nkd+zJ_H_gm+L-w@mail.gmail.com>
> In the datasheet there is no register map. Silead gave us a partial
> register map in order to implement the driver. In the map they
> provided there is no register for resolution or anything that would
> help with this issue. The information in [1] is incomplete and can not
> be considered reliable since the vendor does not say anything about
> it.
That is indeed true.
Relying on parameters read from the ACPI DSDT or the DeviceTree would
certainly be the "clean" way to go on new hardware, but it will not work on
existing hardware where the device parameters are fixed.
Do you think it would make sense to also allow passing the parameters as
module options, or via sysfs for cases where they can't be autodetected?
Also, while going over your code, I found something that might be incorrect.
When you evaluate the point data from the device, you are interpreting it with
this code:
#define SILEAD_POINT_DATA_LEN 0x04
#define SILEAD_POINT_X_OFF 0x02
#define SILEAD_POINT_ID_OFF 0x03
#define SILEAD_X_HSB_MASK 0xF0
#define SILEAD_TOUCH_ID_MASK 0x0F
for (i = 1; i <= touch_nr; i++) {
offset = i * SILEAD_POINT_DATA_LEN;
/* The last 4 bits are the touch id */
id = buf[offset + SILEAD_POINT_ID_OFF] & SILEAD_TOUCH_ID_MASK;
/* The 1st 4 bits are part of X */
buf[offset + SILEAD_POINT_ID_OFF] =
(buf[offset + SILEAD_POINT_ID_OFF] & SILEAD_X_HSB_MASK)
>> 4;
y = le16_to_cpup((__le16 *)(buf + offset));
x = le16_to_cpup((__le16 *)(buf + offset + SILEAD_POINT_X_OFF));
}
The Basewin driver and all the ones derived from it interpreted it like this:
ts->dd = {
.x_index = 6,
.y_index = 4,
.z_index = 5,
.id_index = 7,
}
for(i= 0;i < (touches > MAX_FINGERS ? MAX_FINGERS : touches);i ++) {
x = join_bytes( ( ts->touch_data[ts->dd->x_index + 4 * i + 1] & 0xf),
ts->touch_data[ts->dd->x_index + 4 * i]);
y = join_bytes(ts->touch_data[ts->dd->y_index + 4 * i + 1],
ts->touch_data[ts->dd->y_index + 4 * i ]);
id = ts->touch_data[ts->dd->id_index + 4 * i] >> 4;
}
Or, in other words, your code uses the second-to-last nibble of each record as
the touch id, while the Basewin code uses the last nibble (in little-endian
order).
Please correct me if I am wrong.
next prev parent reply other threads:[~2015-07-13 15:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 21:23 [PATCH] Add generic driver for Silead tochscreens Gregor Riepl
2015-07-12 6:31 ` Dmitry Torokhov
2015-07-13 9:59 ` Robert Dolca
2015-07-13 12:21 ` Gregor Riepl
2015-07-13 14:24 ` Gregor Riepl
2015-07-13 14:52 ` Robert Dolca
2015-07-13 15:18 ` Gregor Riepl [this message]
2015-07-16 13:59 ` Gregor Riepl
2015-07-20 21:19 ` Robert Dolca
2015-07-20 21:13 ` Robert Dolca
2015-07-21 13:21 ` Gregor Riepl
-- strict thread matches above, loose matches on Subject: below --
2015-07-10 15:11 Robert Dolca
2015-07-11 13:05 ` Paul Bolle
2015-07-20 6:51 ` Dmitry Torokhov
2015-07-20 12:05 ` Robert Dolca
2015-07-27 21:30 ` Dmitry Torokhov
2015-07-28 7:23 ` Robert Dolca
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55A3D6DA.9090206@gmail.com \
--to=onitake@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=robert.dolca@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).