On Wed, Oct 5, 2011 at 11:17 AM, Jason Gerecke <[email protected]> wrote: > On Tue, Oct 4, 2011 at 7:22 PM, Chris Bagwell <[email protected]> wrote: >> On Tue, Oct 4, 2011 at 8:00 PM, Jason Gerecke <[email protected]> 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 > > I like the sound of that better than sending BTN_* events, now that > you bring it up. They do have an intended purpose, and it makes sense > to treat them like the multimedia keys found on keyboards. None of the > buttons clearly match up with the semantics though. Would it be better > to send something with the closest semantics (e.g. KEY_PROPS probably > has the closest meaning to what the "i" key is intended to do), or > just vanilla KEY_PROG1 through KEY_PROG3? For the "toggle on-screen > keyboard" key in particular, since nothing has even remotely-close > semantic meaning, should I introduce a new KEY event to the kernel? > > Jason >
...And just as I send that, I *finally* notice the KEY_KEYBOARD event (...I admit I was a little weirded out that the kernel wouldn't have one...). The final question can be ignored :) 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
