On Sat, Oct 23, 2010 at 9:30 PM, Ping Cheng <[email protected]> wrote: > On Sat, Oct 23, 2010 at 3:53 PM, Chris Bagwell <[email protected]> wrote: >> On Thu, Oct 21, 2010 at 2:43 PM, Chris Bagwell <[email protected]> wrote: >>> On Thu, Oct 21, 2010 at 12:38 PM, Ping Cheng <[email protected]> wrote: >>>> On Wed, Oct 20, 2010 at 6:16 PM, <[email protected]> wrote: >>>>> From: Chris Bagwell <[email protected]> >> >> It turns out this version of patch does correctly handle MOUSE devices >> and their buttons because wcmPadChannel == usbChooseChannel() always >> for Protocol 4 and 5 devices. > > I really should read the whole code and try your driver before making > any more comments. TBH, I am not sure if what I am talking about > matches exactly with what you are doing. But, I am running out of time > to try your driver and I do have serious concerns, which is not about > your implementation, it is about the fact that you do not have a > protocol 5 device to test with.
Yeah, that last fact has made life difficult a few times. Anyways, I just send new versions which hopefully address this concern. Hopefully, in new patch #6 I've shown how the code flow is actually the same for Protocol 4 and Protocol 5 devices as before patches. So that should ease concern; especially since I've tested with Protocol 4. > > Once we have your patch in the driver, we will need to update the PAD > code for Intuos and Cintiqs so they don't rely on BTN_TOOL_FINGER for > pad events. The major difference between your Bamboo and the other > models is which port the PAD events are reported from. For Bamboo, it > is from the touch port. For all the others, including Graphires, which > are protocol 4 devices, it is from the digitizer port. If you have > assumed that the PAD data will only come from the PROTOCOL_GENERIC > devcies, i.e. only one tool is associated with the device/port, we'll > run into trouble to split the PAD events from the other tools (stylus, > eraser, and cursor) for other models. > > Do you get what I am talking about? Yes, I believe I understand the concern. The code works based on today's kernel drivers for protocol 4, 5, and generic. If we want to modify those protocol 4/5 kernel drivers then we can make updates to xf86-input-wacom at same time but I purposely didn't support the concept now because it made it harder to read and didn't have a known driver that does it. I'm perfectly comfortable with how today's Wacom multiplexing scheme to separate tools into channels also requires separating pad-like buttons into their own "tool". It solves nicely an issue that even drivers like xf86-input-evdev would have trouble with when some buttons need to stay in-prox and some do not when you change tools (not that xf86-input-evdev should support multiple tools). Chris ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
