Resending: Plain text mode: Some clarifications:the two knobs on the display are configured to be predefined widget areas/shapes. In this case, two pushable knob dials with a predefined center area which acts as a push button. Current knobs report dents or an absolute position, relative data and graduations (although graduations are not well defined yet). Idea was to create two separate input devices (i.e. to associate all reports to these input devices) as the knobs are separately reporting wheel type data, although are part of the same touchscreen. Not clear what ABS_GAS event type is and assumed that REL_HWHEEL was more of a mouse related event code. > > On Thu, Jan 16, 2025 at 1:59 AM Nick Dyer <nick@xxxxxxxxxxxxx> wrote: >> >> 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
