On Wed, Oct 5, 2011 at 12:09 PM, Jason Gerecke <killert...@gmail.com> wrote: > On Wed, Oct 5, 2011 at 1:22 AM, Alexia Death <alexiade...@gmail.com> wrote: >> On Wed, Oct 5, 2011 at 4:00 AM, Jason Gerecke <killert...@gmail.com> wrote: >>> 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 :) >> >> From my cursory look at GDK code long ago having more valuators is >> unlikely to break anything. They just wont be used/supported until >> software gets updated. Breaking the assumptions about the first five >> however is most likely to cause six kinds of havoc. >> >> -- >> --Alexia >> > > Continuing to throw out ideas, if we can turn the touchstrip into > keys/buttons, that opens up a sub-category of the second option: > placing the touch ring data into the touch strip valuators. While this > still has the possibility of breaking things, the fallout should be > minimal given how similar the two are to each other. Applications > which use the touch strip as a relative axis should be completely > unaffected, while those that use it as an absolute axis will be usable > with the caveat that 0% and 100% will be more difficult targets to > achieve (due to the touch rings' increased resolution). This has the > benefit of allowing applications to use both rings without needing to > be rewritten to support XI2, and since the semantic meaning of the > axes are (very nearly) preserved there is little chance of the change > causing problems. > > I'll try adding a 7th valuator to the X driver to see if there are any > obvious breaks that result. I'd also like to hunt down the code in GTK > that reads in the valuators from X, but that'll probably take me a > while... >
After playing around with this a little bit, adding a 7th valuator actually *might* work in existing GTK applications. If I increase the number of valuators exposed by the driver, Gimp 2.6's extended input device setup correctly expands the list of axes available. Actually using that data is another question entirely however. While Gimp seems to get data from the second ring (which even appears to increase and decrease almost as expected), it segfaults after a few seconds of use. That might be due to the quick hack-job I did to make things work, or it might be something deeper. Its hard to say with all the symbols in the backtrace missing. Additionally, this could all be due to GTK3 being smarter under the covers. I need to test the behavior under GTK2 as well... 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
