Hi Jason, Sorry for not replying earlier. 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. > > > > And what if next device adds another wheel? And another... > > > > Do these rings only make sense in the context of entire Cintiq device, > > or maybe they should be treated as ancillary devices (with separate > > input_dev from the main tablet device)? > > > > Thanks. > > > > -- > > Dmitry > > > > 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. > > From a practical standpoint, I don't see tablets with more than two > rings on the horizon. The rings already have mode-switch buttons, > obviating the need for more than one ring per hand. And since the user > only has two hands, it makes the need for more than two rings somewhat > difficult to imagine... For a tablet... But world is not only limited to tablets and so I loathe to have the same conversation about ABS_WHEEL5 in the future. Thanks. -- Dmitry -- 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
