On Wed, Oct 5, 2011 at 1:17 PM, 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?
Its probably case by case. If its a KEY_ bound by Gnome or KDE and has a meaning you don't like then I'd lean more towards KEY_PROG1. I've mostly worked with platform drivers that support hotkeys/multimedia keys on laptops. They declare themselves full out as keyboards and then you get this nice ioctl() to remap your keycode to what ever key at runtime and then can use /lib/udev/rules.d/95-keymap.rules to touch up at run time without recompiling. I think all the drivers/input/touchscreens bypass that stuff and send raw KEY_* without remapping ability. So maybe in that case, its safer to lean towards KEY_PROG? over an inexact match. Chris ------------------------------------------------------------------------------ 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
