On Thu, 16 Jan 2025 at 03:03, Marek Vasut [off-list ref] wrote:

On 1/16/25 2:01 AM, Dmitry Torokhov wrote:

quoted

On Mon, Jan 13, 2025 at 09:08:47PM +0100, Marek Vasut wrote:

quoted

On 1/13/25 8:43 PM, Dmitry Torokhov wrote:

quoted

How about creating separate input devices for these?

This is what I had originally, but ... why ?

This is a single input device, touchscreen with up to two knobs , so why
would it be multiple input devices ?

So as you can see it is hard to express the knobs purpose within a
single input device. Additionally (as far as I understand) knobs are
not connected to the touchscreen function but rather rotary encoders
just happened to be mounted on the touchscreen. They are not considered
contacts.

 From the touch controller perspective, they are contacts.

quoted

Therefore I think it makes sense to report them as 2 separate input
devices (maybe modeling after how drivers/input/misc/rotary-encoder.c
does things).

Not really, the knobs also act as buttons, so the user might navigate a
finger on the touch surface to point to an object, and turn or press the
knob to trigger some action. This is similar to the Dell Canvas 27 knob
already mentioned above, except that one was not glued to the glass, it
was movable.

As an observation: atmel_mxt_ts already supports the T15 key array.
This turns an area of the matrix into a series of keys, which the
driver registers and will report in mxt_proc_t15_messages().

I think we see these as being similar to scrollwheels or side buttons
on a mouse - they are very associated with the pointing device itself.

Nick