On Thu, 16 Jan 2025 at 03:03, Marek Vasut <marex@xxxxxxx> wrote: > > On 1/16/25 2:01 AM, Dmitry Torokhov wrote: > > On Mon, Jan 13, 2025 at 09:08:47PM +0100, Marek Vasut wrote: > >> On 1/13/25 8:43 PM, Dmitry Torokhov wrote: > >>> 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. > > > 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
