On Sun, Oct 9, 2011 at 9:25 PM, Jason Gerecke <[email protected]> wrote:
> On Sun, Oct 9, 2011 at 5:36 PM, Chris Bagwell <[email protected]> wrote:
>> On Sun, Oct 9, 2011 at 6:08 PM, Peter Hutterer <[email protected]>
>> wrote:
>>> On Fri, Oct 07, 2011 at 06:34:01PM -0700, Jason Gerecke wrote:
>>>>
>>>> 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.
>
It could be as simply as modifying the current EV_KEY logic in
usbDispatchEvents() to look like this:
if (usbParseKeyEvent(common, event, ds, &dslast))
channel_change |= 1;
else if (usbParseBTNEvent(common, event, btn_ds))
channel_change |= 1;
else
xf86PostKeyboardEvent(pInfo->dev,
event.key, event.value);
Real buttons would need to be added to padkey_codes[] still but
everything else would be treated as keys.
Since keys are not USB specific concept, it probably belongs in
wcmCommon somehow.
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
