linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Budig <simon.budig@kernelconcepts.de>
To: Henrik Rydberg <rydberg@euromail.se>
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com,
	olivier@sobrie.be, agust@denx.de, yanok@emcraft.com
Subject: Re: [PATCH v6] Touchscreen driver for FT5x06 based EDT displays
Date: Mon, 25 Jun 2012 11:27:37 +0200	[thread overview]
Message-ID: <4FE82F09.8020203@kernelconcepts.de> (raw)
In-Reply-To: <20120625085113.GA648@polaris.bitmath.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Henrik.

On 06/25/2012 10:51 AM, Henrik Rydberg wrote:
>> [Sysfs files]
> 
> I would very much prefer if the driver functioned well without
> such settings, since they complicate userspace and are not likely
> to ever go away. Oh well.

I would prefer to have the touchscreen adjust itself as well,
unfortunately this is not available and you definitely need different
settings depending for different touch setups.

Would an ioctl() be more acceptable? Would make it harder to adjust it
in startup scripts etc. though.

>> +	if (error) { +		dev_err(&tsdata->client->dev, +			"Unable to
>> write to fetch data, error: %d\n", error); +		goto out; +	}
> 
> No risk of flooding the logs here? Perhaps rate-limit the outputs?

Hmm, possible. Can you point me to a driver that does this in a sane
fashion?

>> +	for (i = 0; i < MAX_SUPPORT_POINTS; i++) { +		u8 *buf =
>> &rdbuf[i * 4]; +		bool down; + +		type = buf[5] >> 6; +		/*
>> ignore Reserved events */ +		if (type == TOUCH_EVENT_RESERVED) +
>> continue;
> 
> As per the implementation by Olivier, it seems these touches may
> get stuck in the down position. No?

Not if you do the loop over all 5 event entries in the report. The
n_touches field really contains the number of fingers on the touch,
not the number of events in the report. Since the "down"-events
conveniently are sorted to the beginning of the report for the type A
protocol it was enough to to just iterate over these (we ignored the
UP-events anyway). Now that we need them we just iterate over all of
the events and there they are.

>> +	tsdata->threshold = edt_ft5x06_i2c_register_read(tsdata, +
>> WORK_REGISTER_THRESHOLD); +	tsdata->gain =
>> edt_ft5x06_i2c_register_read(tsdata, +						WORK_REGISTER_GAIN); 
>> +	tsdata->offset = edt_ft5x06_i2c_register_read(tsdata, +
>> WORK_REGISTER_OFFSET); +	tsdata->report_rate =
>> edt_ft5x06_i2c_register_read(tsdata, +
>> WORK_REGISTER_REPORT_RATE); +	tsdata->num_x =
>> edt_ft5x06_i2c_register_read(tsdata, +
>> WORK_REGISTER_NUM_X); +	tsdata->num_y =
>> edt_ft5x06_i2c_register_read(tsdata, +
>> WORK_REGISTER_NUM_Y); + +	dev_dbg(&client->dev, +		"Model \"%s\",
>> Rev. \"%s\", %dx%d sensors\n", +		tsdata->name, fw_version,
>> tsdata->num_x, tsdata->num_y); + +	input->name = tsdata->name; +
>> input->id.bustype = BUS_I2C; +	input->dev.parent = &client->dev; 
>> + +	__set_bit(EV_SYN, input->evbit); +	__set_bit(EV_KEY,
>> input->evbit); +	__set_bit(EV_ABS, input->evbit); +
>> __set_bit(BTN_TOUCH, input->keybit); +
>> input_set_abs_params(input, ABS_X, 0, tsdata->num_x * 64 - 1, 0,
>> 0); +	input_set_abs_params(input, ABS_Y, 0, tsdata->num_y * 64 -
>> 1, 0, 0); +	input_set_abs_params(input, ABS_MT_POSITION_X, +
>> 0, tsdata->num_x * 64 - 1, 0, 0); +	input_set_abs_params(input,
>> ABS_MT_POSITION_Y, +			     0, tsdata->num_y * 64 - 1, 0, 0); +
>> input_mt_init_slots(input, MAX_SUPPORT_POINTS);
> 
> No error checking here?

I guess you're referring to the _register_read()s? Yeah, they probably
could use some.

Thanks,
        Simon

- -- 
       Simon Budig                        kernel concepts GmbH
       simon.budig@kernelconcepts.de      Sieghuetter Hauptweg 48
       +49-271-771091-17                  D-57072 Siegen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/oLwkACgkQO2O/RXesiHCSHgCdHV7OHSfBVrePLL4F19j+MwvH
lkYAoIfI9X61yTWwG1AFcaGiJhefdShr
=wpmW
-----END PGP SIGNATURE-----

  reply	other threads:[~2012-06-25  9:27 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1326413229-30282-1-git-send-email-simon.budig@kernelconcepts.de>
2012-01-13  0:13 ` [PATCH v3] Touchscreen driver for FT5x06 based EDT displays simon.budig
2012-01-13  0:13   ` [PATCH] " simon.budig
2012-03-06 16:15   ` [PATCH v4] " simon.budig
2012-03-06 16:15     ` simon.budig
2012-03-07 10:42       ` Simon Budig
2012-03-07 13:36       ` Anatolij Gustschin
2012-03-07 14:50         ` Simon Budig
2012-04-04 18:27     ` [PATCH v5] " simon.budig
2012-04-04 18:27       ` [PATCH] " simon.budig
2012-04-04 19:10         ` Dmitry Torokhov
2012-04-04 20:52           ` Simon Budig
2012-04-04 21:09             ` Dmitry Torokhov
2012-04-05 10:27               ` Simon Budig
2012-04-05 12:54           ` Simon Budig
2012-05-07  6:57             ` Dmitry Torokhov
2012-06-22 23:48         ` [PATCH v6] " simon.budig
2012-06-22 23:48           ` simon.budig
2012-06-25  7:20             ` Dmitry Torokhov
2012-06-25  8:53               ` Henrik Rydberg
2012-06-25  8:51             ` Henrik Rydberg
2012-06-25  9:27               ` Simon Budig [this message]
2012-06-25 11:34                 ` Henrik Rydberg
2012-06-26  1:36                   ` Dmitry Torokhov
2012-06-26  5:37                 ` Olivier Sobrie
2012-06-26  2:06               ` Dmitry Torokhov
2012-06-26  9:06                 ` Simon Budig
2012-06-26 18:21                   ` Henrik Rydberg
2012-06-26 19:17                 ` Henrik Rydberg
2012-06-24 12:31           ` Simon Budig
2012-07-01 20:36           ` [PATCH v7] " simon.budig
2012-07-01 20:36             ` simon.budig
2012-07-02  9:31               ` Henrik Rydberg
2012-07-02  9:55                 ` Simon Budig
2012-07-08 16:05             ` [PATCH v8] " simon.budig
2012-07-08 16:05               ` simon.budig
2012-07-09  8:06                 ` Henrik Rydberg
2012-07-19  4:16                   ` Dmitry Torokhov
2012-07-19 13:50                     ` Henrik Rydberg
2012-07-19 13:56                       ` Simon Budig
2012-07-22 15:02               ` [PATCH v9] " simon.budig
2012-07-23 16:54                 ` Dmitry Torokhov
2012-07-23 17:45                   ` Henrik Rydberg
2012-07-24 20:06                     ` Simon Budig
2012-07-24 20:26                       ` Dmitry Torokhov

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=4FE82F09.8020203@kernelconcepts.de \
    --to=simon.budig@kernelconcepts.de \
    --cc=agust@denx.de \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=olivier@sobrie.be \
    --cc=rydberg@euromail.se \
    --cc=yanok@emcraft.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).