Re: New "ABS_WHEEL2" axis?

On Thu, Oct 06, 2011 at 01:31:09PM -0700, Jason Gerecke wrote:

quoted

On Wed, Oct 5, 2011 at 8:34 PM, Dmitry Torokhov
[off-list ref] wrote:

quoted

On Wednesday, October 05, 2011 12:44:40 PM Jason Gerecke wrote:

quoted

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" ;).

quoted

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.

Ping