Re: New "ABS_WHEEL2" axis?

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Thu, Dec 01, 2011 at 02:04:00PM -0800, Jason Gerecke wrote:
> On Thu, Dec 1, 2011 at 9:13 AM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> > On Wed, Nov 30, 2011 at 11:11 PM, Dmitry Torokhov
> > <dmitry.torokhov@gmail.com> wrote:
> >> On Wed, Nov 30, 2011 at 03:52:55PM -0800, Jason Gerecke wrote:
> >>> On Wed, Nov 30, 2011 at 3:19 PM, Dmitry Torokhov
> >>> <dmitry.torokhov@gmail.com> wrote:
> >>> > On Wed, Nov 30, 2011 at 02:42:09PM -0800, Ping Cheng wrote:
> >>> >> > On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:
> >>> >> >> On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
> >>> >> >> <dmitry.torokhov@gmail.com> wrote:
> >>> >> >> > On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:
> >>> >> >> >> I'm working on adding support for the recently-announced Cintiq 24HD,
> >>> >> >> >> and am hashing out most of the details on the linuxwacom mailing list.
> >>> >> >> >> In the discussions there, it was suggested that we add a new e.g.
> >>> >> >> >> "ABS_WHEEL2" axis to the input.h header to represent the second touch
> >>> >> >> >> ring available on the 24HD. I think it's a good idea, but wanted to
> >>> >> >> >> get some opinions from over here before making a patch. The other
> >>> >> >> >> option we have available is to use an axis not already in use by the
> >>> >> >> >> wacom driver (such as ABS_RUDDER), but none have a matching semantic
> >>> >> >> >> meaning.
> >>> >> >
> >>> >> > Looking at this once more ABS_WHEEL does not semantically match to what
> >>> >> > Wacom driver users it for either. ABS_WHEEL is not "an abstract
> >>> >> > circular-shaped sensor on a device" for rather a "steering wheel"-like
> >>> >> > control on a game controller. So Wacom needs to move away from using this
> >>> >> > event.
> >>> >>
> >>> >> We can move away from using the WHEEL. But, we do still need to use
> >>> >> something to report the values. We need a constructive suggestion to
> >>> >> "move away" ;).
> >>> >>
> >>> >> >> The rings are controls built into the "pad" -- the hardware you bring
> >>> >> >> the stylus in proximity to. Along with the touch rings, there are also
> >>> >> >> buttons and touch strips. Now, some devices have controls on only the
> >>> >> >> left-hand side of the pad, while others have the controls on both
> >>> >> >> sides of the pad. While one could argue that this makes each "side" a
> >>> >> >> complete context that can be broken apart into separate devices, that
> >>> >> >> doesn't really solve anything. What's stopping us from grouping
> >>> >> >> several rings together?
> >>> >> >
> >>> >> > Well, there are several topics here...
> >>> >> >
> >>> >> > What you apparently have is a group of unclassified, as far as Linux
> >>> >> > input subsystem concerned, sensors. When I say unclassified I mean that
> >>> >> > there is no appropriate event code we can assign to the control to allow
> >>> >> > a generic consumer determine the purpose of that sensor. You need help
> >>> >> > of a specialized driver to decide what to do with the data or, in case
> >>> >> > of generic driver, user has to explicitly map it to some action, but
> >>> >> > there is no way for automatic discovery/configuration which is the goal
> >>> >> > of input core. The only and closest event that we have that is suitable
> >>> >> > here is ABS_MISC.
> >>> >> >
> >>> >> > Here however is a problem: there is only one ABS_MISC and we often have
> >>> >> > several such sensors on a device. I do not want to have ABS_MISCx as
> >>> >> > again, it does not solve anything, manufactures always come with bigger
> >>> >> > and bigger devices (there some music controllers with dozens of
> >>> >> > sliders). Encoding data into ABS_MISC (let's say highest byte denotes
> >>> >> > sensor number) is awkward as well. So that is why I propose splitting
> >>> >> > them into separate input devices and have driver discover and handle
> >>> >> > them as it sees fit.
> >>> >>
> >>> >> The rings are on the tablet. Events from them are combined with the
> >>> >> events from the other tools moving on the tablet. Splitting the
> >>> >> wheels/expresskeys from the tablet would only complicate the
> >>> >> situation. We would have to link the wheels back to the tablet in the
> >>> >> user land, an unnecessary step that we should/could avoid in the
> >>> >> kernel.
> >>> >
> >>> > The fact that they are in the same physical package does not mean that
> >>> > they are necessarily mapped to a single input device. For example my USB
> >>> > keyboard consists of 3 logical devices.
> >>> >
> >>> > I understand that having data from them in the same event stream would
> >>> > be nice and if you have an idea how to achieve that in a generic way
> >>> > without resorting to ABS_MISC55 - that would be great. Maybe we
> >>> > need something similar to multitouch protocol solution, but for
> >>> > unclassified data.
> >>> >
> >>> > OTOH separate input devices complicate userland in cases when driver
> >>> > wants to handle them together but is really flexible.
> >>> >
> >>> > --
> >>> > Dmitry
> >>>
> >>> Confound my slow reply speeds... I was just about to hit the "send"
> >>> button too! :D
> >>>
> >>> I'm not sure there is a good solution given the current expectations
> >>> of and by the input subsystem. Abusing/ignoring semantic meaning of
> >>> axes can confuse the userland. Arbitrarily adding new axes is not
> >>> sustainable. Splitting the hardware into per-sensor devices requires
> >>> additional needlesly-difficult re-unification code.
> >>>
> >>> Augmenting the input subsystem with something similar to the MT
> >>> protocol would be one possible way of "properly" tackling the issue.
> >>> You'd have to figure out a way to deal with arbitrary tool types
> >>> though. For instance, say the touch strip on the 24HD were exposed to
> >>> the user as a strip and not faux-buttons. Two of the three
> >>> unclassified sensors producing the same "kind" of data, while the
> >>> third sensor produces a different "kind" of data.
> >>
> >> Right, this requires knowledge in userspace driver as to how use the
> >> data from different sensors. But that is not different from
> >> ABS_WHEEL/ABS_WHEEL2 - _your_ driver knows what they mean but a generic
> >> either has no idea or even a wrong idea.
> >>
> >>>
> >>> Regardless, how should we handle the issue that presents itself in the
> >>> here-and-now? Even if refactoring things to split the tablet into more
> >>> devices is the route we ultimately decide on, that's going to take
> >>> some time to implement. It'd be nice if 24HD support weren't stalled
> >>> waiting for yet-to-be-written code to appear, and preferable if the
> >>> hardware worked in its entirety (meaning substituting ABS_WHEEL2 with
> >>> e.g. ABS_THROTTLE for the time being).
> >>>
> >>
> >> Probably multiplexing through ABS_MISC would be not too painful as an
> >> interim solution.
> >>
> Multiplexing is certainly simpler than splitting the tablet into
> multiple devices. It's not, however, as simple as it seems. If we only
> put the right touch ring into ABS_MISC, it wouldn't be too bad; we
> could write some trivial placeholder code for the moment and get back
> to fleshing it out when we get some time. That's not an option though
> since ABS_MISC is already being used to send tool type information.
> Placeholder code wouldn't cut it and we'd have to rewrite portions of
> the kernel and X driver right now.
> 
> Please don't misunderstand -- I agree that multiplexing is a
> reasonable interim solution, and I'm not against doing the work. I
> just don't have any time in my schedule right now to devote to it.
> 
> That's why I'd prefer using an existing axis that we don't already
> use. The code is already written and tested, and our driver already
> abuses the semantics of so many other axes that a program trying to
> use the kernel events in a generic way will fail spectacularly anyway.
> If we don't find time to refactor things in the near future, we can
> schedule time up-front with the next device that requires yet another
> axis on the assumption that you would block any more patches which
> further this cycle of semantic abuse.

I suppose I'd be OK with [ab]using one of existing "free" axes for the
time being, given that we require a specific driver for full support of
wacom tablets anyway.

Thanks.

-- 
Dmitry