On Tue, Oct 4, 2011 at 8:00 PM, Jason Gerecke <killert...@gmail.com> wrote: > I'm working on adding support for the recently-announced Cintiq 24HD. > It's pretty straightforward, but there are two interesting bits that > I'd like some guidance on. > > Firstly, the 24HD has three "hardware control buttons" along the top > edge which are physically implemented as a touch strip. While it could > in theory be used *as* a touch strip, the fact that it is one is > completely non-obvious. The manual refers to them as buttons, they > have painted-on icons like buttons, and each are in a fingertip-sized > indentation like a button (I only found out it was a touchstrip by > watching evdev). Leaving them as a touch strip isn't likely to cause > problems, but I feel there is also merit to the concept of translating > them into buttons. Thoughts? Opinions? >
A somewhat related example is clickpads... touchpads with buttons integrated into the touchpad. There is only 1 button click reported and its translated into a left, middle, or right click based on the X/Y value during the click. I've seen a version were it was done in kernel driver and reported as BTN_LEFT/etc. That had issues because sometimes they wanted it to be button click and other times real X/Y coordinates. So that becomes a userland issue. For this case though, I'd probably do it in the driver. On the wacom webpage for 24HD, I see 3 buttons with "i", a keyboard symbol, and a wrench. It sounds to me like they are meant more for launching programs then anything else (a help app, a onscreen keyboard, and what I think USB HID calls Config button respectively). If that is there intended purpose then I would send KEY_* values instead of ABS_* or BTN_* values. The former are super easy to bind into window managers hotkeys and launch stuff. The later are not easy at all to use by window manager for global meanings. I'm not as good with real rings so I'll leave that for others to offer advise. Chris > > Secondly, the 24HD adds a second touchring to the mix, which means > trying to figure out the best way to get its data out of the kernel > and X driver: > > For the kernel driver, there are a few different axes we could put the > data into. There are benefits and drawbacks to each, and input on the > balance each option achieves would be appreciated. > > * ABS_WHEEL: Using this axis means the second ring will work with > current X11 drivers. However, since both rings are stored in the same > axis, it will be impossible to seperate out the data at a later time. > Additionally, simultaneous use of the two rings may have unexpected > effects as the axis value jumps around. > > * ABS_Z: Using this axis means the second ring will work with current > X11 drivers (ds->abswheel stores ABZ_Z and ABS_WHEEL alike). New > drivers could add a new field to the devicestate to keep the two rings > seperate, allowing independent use. However, since ABS_Z is *already* > being used to store stylus barrel rotation, clients other than our own > X11 driver may break in unexpected ways when the second ring is used. > > * ABS_RZ: Using this axis will cause the second ring to not work at > all in current X11 drivers (ds->rotation, where ABS_RZ is stored, is > ignored for the pad device). Additionally, since ABS_RZ is already in > use for 4D mouse rotation, clients other than our own X11 driver may > break in unexpected ways when the second ring is used. That said, if > possible breakage for this one axis on this one tool is acceptable, it > may be a more logical solution. ABS_RX and ABS_RY already contain > touch strip data, and 4D mouse rotation arguably belongs in ABS_Z > anyway (it has both the same semantics and possible range of values). > > * ABS_RUDDER: Using this (or another similar) axis will cause the > second ring to not work at all in current X11 drivers. However, since > this axis is not currently emitted by our kernel driver, the chance of > breaking clients other than our own driver is minimal. Additionally, > by having the ring on an axis to itself it is possible to advertise > the correct range of values to clients (which would also be the case > if 4D mouse rotation is moved off the ABS_RZ axis). This may not be > that important though -- ABS_WHEEL already violates this by sharing > the left touch ring (range 0..71) and airbrush fingerwheel (range > 0..1023). > > For the X driver, we run into a backwards-compatibility problem > (...unless we go the lame route with ABS_WHEEL). While XI2 provides up > to 36 valuators, I believe there was a limit of 6 valuators at some > point in the past. With the pad device having 3 axes reserved for > X/Y/P, and 2 axes reserved for touch strips, there's just not enough > room for both touch rings. We can break apps that were written with > the 6 valuator limit in mind or break apps that assume the first 5 > axes are X/Y/P/TSl/TSr. I'm not sure what kind of fall-out to expect > from either option, so any insight would be appreciated :) > > Jason > > --- > Day xee-nee-svsh duu-'ushtlh-ts'it; > nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. > Huu-chan xuu naa~-gha. > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Linuxwacom-devel mailing list > Linuxwacom-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
