The Graphire 3 doesn't really have a pad, while the 4 does, so I'm
actually surprised that its the former that broke rather than the
latter. I'd imagine the G3 could get away with the generic protocol
without any problems. I didn't test the pad buttons with another
device in prox on the G4 so its possible its broken in that regard as
well, but even if it were, its still not as bad off as the G3 is.

Jason

---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.

On Wed, Dec 7, 2011 at 12:33 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote:
> On Wed, Dec 7, 2011 at 2:14 PM, Jason Gerecke <killert...@gmail.com> wrote:
>> This patch breaks puck buttons on the Graphire 3. Motion gets through
>> fine, but clicking (left, middle, or right) is impossible.
>> Interestingly, scrolling still works. Graphire 4 is unaffected.
>
> I see.  Thank you for testing.  That means Graphires+xf86-input-wacom
> only work with Protocol 4 events after all.  I think I see one issue
> in xf86-input-wacom that needs to be fixed.  I'll submit a patch for
> it soon.
>
> There is an issue in wcmUsbInit() where it tries to make sure npadkeys
> is at least a minimum size (needs to be at least 5 for Graphire cases
> I think).  That logic was protected by a if (!supports_mouse_puck); I
> think the if() was not really needed.
>
> Since we are moving to Mice and Tablets re-using the same event names
> and no way for kernel to tell us exact list associated with each
> "tool" (mouse puck vs tablet buttons), we will have to always reserve
> worst case size for both "tool" types.
>
> Related to this, since we can't tell which "tool" is sending the
> event, we must chose which to route it to inside xf86-input-wacom.
> Today, its always routing to Tablet/PAD device and since npadkeys is
> wrong value, its why it gets dropped.  We can improve upon that a
> little and look at BTN_TOOL_MOUSE value I suppose to chose between
> CURSOR and PAD device... that approach would align with a choice I
> made in the 3rd patch in series... but todays xf86-input-wacom
> approach was my best effort to try to solve that logic issue without
> having a device at hand.
>
> Chris
>
>>
>> Jason
>>
>> ---
>> Day xee-nee-svsh duu-'ushtlh-ts'it;
>> nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
>> Huu-chan xuu naa~-gha.
>>
>>
>>
>> On Thu, Dec 1, 2011 at 8:02 PM,  <ch...@cnpbagwell.com> wrote:
>>> From: Chris Bagwell <ch...@cnpbagwell.com>
>>>
>>> For graphire, the ABS_MISC was never sending any information
>>> beyond what BTN_TOOL_* was providing.  So remove sending
>>> event.
>>>
>>> Bamboo P&T and a left over send for the pen tool even though
>>> capability wasn't declared.  So remove as well.
>>>
>>> Signed-off-by: Chris Bagwell <ch...@cnpbagwell.com>
>>> ---
>>>  drivers/input/tablet/wacom_wac.c |    6 ++----
>>>  1 files changed, 2 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/input/tablet/wacom_wac.c 
>>> b/drivers/input/tablet/wacom_wac.c
>>> index 6c3ff00..7b69a21 100644
>>> --- a/drivers/input/tablet/wacom_wac.c
>>> +++ b/drivers/input/tablet/wacom_wac.c
>>> @@ -263,7 +263,6 @@ static int wacom_graphire_irq(struct wacom_wac *wacom)
>>>
>>>                if (!prox)
>>>                        wacom->id[0] = 0;
>>> -               input_report_abs(input, ABS_MISC, wacom->id[0]); /* report 
>>> tool id */
>>>                input_report_key(input, wacom->tool[0], prox);
>>>                input_sync(input); /* sync last event */
>>>        }
>>> @@ -280,7 +279,6 @@ static int wacom_graphire_irq(struct wacom_wac *wacom)
>>>                        input_report_rel(input, REL_WHEEL, rw);
>>>                        if (!prox)
>>>                                wacom->id[1] = 0;
>>> -                       input_report_abs(input, ABS_MISC, wacom->id[1]);
>>>                        retval = 1;
>>>                }
>>>                break;
>>> @@ -296,7 +294,6 @@ static int wacom_graphire_irq(struct wacom_wac *wacom)
>>>                        input_report_abs(input, ABS_WHEEL, (data[8] & 0x7f));
>>>                        if (!prox)
>>>                                wacom->id[1] = 0;
>>> -                       input_report_abs(input, ABS_MISC, wacom->id[1]);
>>>                        retval = 1;
>>>                }
>>>                break;
>>> @@ -962,7 +959,6 @@ static int wacom_bpt_pen(struct wacom_wac *wacom)
>>>        }
>>>
>>>        input_report_key(input, wacom->tool[0], prox); /* PEN or RUBBER */
>>> -       input_report_abs(input, ABS_MISC, wacom->id[0]); /* TOOL ID */
>>>
>>>        return 1;
>>>  }
>>> @@ -1154,6 +1150,8 @@ void wacom_setup_input_capabilities(struct input_dev 
>>> *input_dev,
>>>                /* fall through */
>>>
>>>        case GRAPHIRE:
>>> +               __clear_bit(ABS_MISC, input_dev->absbit);
>>> +
>>>                input_set_capability(input_dev, EV_REL, REL_WHEEL);
>>>
>>>                __set_bit(BTN_LEFT, input_dev->keybit);
>>> --
>>> 1.7.7.3
>>>

------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to