On Tue, Oct 04, 2011 at 06:00:28PM -0700, Jason Gerecke 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?
meh. if they're buttons in the manual, they look like buttons and are
designed to be buttons, let's just export them as buttons.
> 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).
add ABS_WHEEL2 to the kernel. for better or worse, input events in the
kernel all have a semantic meaning. trying to hack around that just causes
pain. Remember that the kernel is supposed to be a device abstraction layer
so that whatever comes out of it is reasonably generic. it's not just an API
conversion so that you need wacom-specific tools on both sides.
> 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 :)
sooner or later we will have to break those apps. I think Alexia may have
more comments here, the last one I found was
"GTK event handling code that feeds gimp has fixed struct of 6
axis. Stuffing an extra axis would kill the tool for all past versions
of GIMP and anything thats relased months to a year in the future,
because GTK wont catch up and then a lot of code in gimp that deals
with coord structs would need to change too. Its a crap-ton of code
and even I dont know where changing the coords structs can lead."
Cheers,
Peter
------------------------------------------------------------------------------
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
