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. Cheers, Peter ------------------------------------------------------------------------------ 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
