On Wed, Oct 5, 2011 at 12:52 PM, Chris Bagwell <[email protected]> wrote: > 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 >
Played around with implementing this, and it doesn't look like there's much benefit to using KEY events over BTN events at the moment (while using the xf86-input-wacom driver anyway). Both BTN_N and KEY_PROG are both actually interpreted identically and posted to X via xf86PostButtonEvent. As it stands, even though the kernel is sending e.g. KEY_PROG1, the X driver will send button ~20. Of course, sending KEY_PROG? is no harder than sending BTN_N, so I think I'll keep with this course of action. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
