On Fri, Mar 18, 2011 at 6:07 PM, Chris Bagwell <[email protected]> wrote:
>
> > You suggested we stay with BTN_# for pad, right? So, if we do not move
> PAD
> > buttons to BTN_LEFT/RIGHT. No issues here either.
>
> Because Bamboo's are using BTN_LEFT/RIGHT on bad, all "generic"'s are
> routing those buttons to PAD. So unless code is added, the Graphire
> generic will route mouse puck's buttons to PAD.
>
Good point! I came up with another idea to leave Graphire to protocol 4.
I'll work on it next week. The new solution covers protocol 5 as well. It
requires minimal change in the kernel and a small chunk in wcmUSB.c.
>> In other email, I mentioned I think its easier to treat REL_WHEEL as
> >> PAD event *always* in xf86-input-wacom. User won't know difference.
> >
> > You mentioned this idea above in your commit message too.
> >
> > User will see the difference since they get a PAD tool when there is no
> pad
> > on the tablet. For example, Graphire 1, 2, and 3 all have relative wheel
> > mouse. If we treat REL_WHEEL as a pad button, we are adding a pad tool
> for
> > those devices.
>
> I *think* all devices with wheels (REL and ABS) also have PAD tools.
> But I'm not positive.
>
No. You are wrong this time ;). Graphire 1 to 3 all have relative mouse. But
none of them have tablet keys or wheels.
You'll see my new approach when I have the patch ready.
Ping
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
