From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Javier Carrasco <javier.carrasco@wolfvision.net>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
Bastian Hecht <hechtb@gmail.com>,
Michael Riesch <michael.riesch@wolfvision.net>,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Jeff LaBundy <jeff@labundy.com>
Subject: Re: [PATCH v10 2/4] Input: touch-overlay - Add touchscreen overlay handling
Date: Thu, 11 Jul 2024 10:18:11 -0700 [thread overview]
Message-ID: <ZpAT01jr9rS55t_B@google.com> (raw)
In-Reply-To: <d8734538-81f4-4883-bd29-2f8b682c3d1c@wolfvision.net>
On Wed, Jul 10, 2024 at 02:16:13PM +0200, Javier Carrasco wrote:
> On 09/07/2024 02:08, Dmitry Torokhov wrote:
> > Hi Javier,
> >
> > On Wed, Jun 26, 2024 at 11:56:14AM +0200, Javier Carrasco wrote:
> >> Some touch devices provide mechanical overlays with different objects
> >> like buttons or clipped touchscreen surfaces.
> >
> > Thank you for your work. I think it is pretty much ready to be merged,
> > just a few small comments:
> >
> >>
> >> In order to support these objects, add a series of helper functions
> >> to the input subsystem to transform them into overlay objects via
> >> device tree nodes.
> >>
> >> These overlay objects consume the raw touch events and report the
> >> expected input events depending on the object properties.
> >
> > So if we have overlays and also want to invert/swap axis then the
> > overlays should be processed first and only then
> > touchscreen_set_mt_pos() or touchscreen_report_pos() should be called?
> >
> > But then it will not work if we need help frm the input core to assign
> > slots in cases when touch controller does not implement [reliable]
> > contact tracing/identification.
> >
> > I think this all needs to be clarified.
> >
>
> I think this is the most critical point from your feedback.
>
> So far, touch-overlay processes the coordinates of input_mt_pos elements
> before passing them to touchscreen_set_mt_pos(). As you pointed out,
> that means that it does not act on the slots i.e. it assumes that the
> controller does the contact tracing and pos[i] is assigned to slot[i],
> which is wrong.
>
> Current status:
> [Sensor]->[touch-overlay(filter + button
> events)]->[touchscreen_set_mt_pos()]->[input_mt_assign_slots()]->[report
> MT events]
>
> If I am not mistaken, I would need a solution that processes the
> coordinates associated to assigned slots via input_mt_assign_slots().
> Then I would have to avoid generating MT events from slots whose
> coordinates are outside of the overlay frame (ignored) or on overlay
> buttons (generating button press/release events instead).
>
> But once input_mt_assign_slots() is called, it is already too late for
> that processing, isn't it? Unless assigned slots filtered by
> touch-overlay are kept from generating MT events somehow, but still used
> to keep contact tracing.
>
> Any suggestion on this respect would be more than welcome.
The driver is in control which slots to emit the events for, so it can
skip reporting if it wants. Consider the st1232 for which you are making
these adjustments:
for (i = 0; i < ts->chip_info->max_fingers; i++) {
u8 *buf = &ts->read_buf[i * 4];
if (buf[0] & BIT(7)) {
unsigned int x = ((buf[0] & 0x70) << 4) | buf[1];
unsigned int y = ((buf[0] & 0x07) << 8) | buf[2];
touchscreen_set_mt_pos(&pos[n_contacts],
&ts->prop, x, y);
/* st1232 includes a z-axis / touch strength */
if (ts->chip_info->have_z)
z[n_contacts] = ts->read_buf[i + 6];
n_contacts++;
}
}
input_mt_assign_slots(input, slots, pos, n_contacts, 0);
for (i = 0; i < n_contacts; i++) {
input_mt_slot(input, slots[i]);
input_mt_report_slot_state(input, MT_TOOL_FINGER, true);
input_report_abs(input, ABS_MT_POSITION_X, pos[i].x);
input_report_abs(input, ABS_MT_POSITION_Y, pos[i].y);
if (ts->chip_info->have_z)
input_report_abs(input, ABS_MT_TOUCH_MAJOR, z[i]);
}
Can you call touch_overlay_process_event() from the 2nd for() loop,
something like this:
for (i = 0; i < n_contacts; i++) {
if (touch_overlay_process_event(&ts->touch_overlay_list,
input,
&pos[i].x, &pos[i].y))
continue;
input_mt_slot(input, slots[i]);
...
}
Note that you will no longer able to rely on the input core to drop
"unused" slots because you may need to generate "key up" events for
them, but you do have access to input_mt_is_active() and
input_mt_is_used() so you can implement what you need.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2024-07-11 17:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-26 9:56 [PATCH v10 0/4] Input: support overlay objects on touchscreens Javier Carrasco
2024-06-26 9:56 ` [PATCH v10 1/4] dt-bindings: touchscreen: add touch-overlay property Javier Carrasco
2024-06-26 9:56 ` [PATCH v10 2/4] Input: touch-overlay - Add touchscreen overlay handling Javier Carrasco
2024-07-09 0:08 ` Dmitry Torokhov
2024-07-10 12:16 ` Javier Carrasco
2024-07-11 17:18 ` Dmitry Torokhov [this message]
2024-06-26 9:56 ` [PATCH v10 3/4] dt-bindings: input: touchscreen: st1232: add touch-overlay example Javier Carrasco
2024-06-26 9:56 ` [PATCH v10 4/4] Input: st1232 - add touch overlays handling Javier Carrasco
2024-07-09 0:44 ` 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=ZpAT01jr9rS55t_B@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hechtb@gmail.com \
--cc=javier.carrasco@wolfvision.net \
--cc=jeff@labundy.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.riesch@wolfvision.net \
--cc=robh@kernel.org \
/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).