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? 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
