Re: New "ABS_WHEEL2" axis?

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

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.

-- 
Dmitry