On Sun, Oct 9, 2011 at 5:36 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: > On Sun, Oct 9, 2011 at 6:08 PM, Peter Hutterer <peter.hutte...@who-t.net> > wrote: >> On Fri, Oct 07, 2011 at 06:34:01PM -0700, Jason Gerecke wrote: >>> On Wed, Oct 5, 2011 at 12:52 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: >>> > On Wed, Oct 5, 2011 at 1:17 PM, Jason Gerecke <killert...@gmail.com> >>> > wrote: >>> >> On Tue, Oct 4, 2011 at 7:22 PM, Chris Bagwell <ch...@cnpbagwell.com> >>> >> wrote: >>> >>> On Tue, Oct 4, 2011 at 8:00 PM, Jason Gerecke <killert...@gmail.com> >>> >>> 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. >> >> that's a bit... weird. KEY_* events should never be posted through >> xf86PostButtonEvent unless there's a bug in the driver. >> > > I understand why we are not posting them as keys and we can eventually > fix that in driver; doing same logic as xf86-input-evdev does. > > But I can't quite explain why KEY_PROG is sending a button press. Did > you add it to padkey_codes[] or something? > > It you didn't then we probably have some bug in how we are computing > npadkeys and looking an uninitialized array that happens to match > KEY_PROG value. For that matter, I can't explain BTN_N working either > since its not in padkey_codes[] either. > > Chris >
Yeah, I put them into padkey_codes[] to get them to work. If you've got an idea for how to properly fix the driver to emit keyboard events for KEY_*, I'm all ears. 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
