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 ------------------------------------------------------------------------------ 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
