> 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@xxxxxxxxx> 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. Ping -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
