On Sat, Jul 16, 2011 at 12:19 PM, Roald Frederickx <[email protected]> wrote: > Hi, > > Thanks for the elaborate answer! > > I've implemented ABS_MISC events with the device ID that got returned > from the hardware. However, this seems to have introduced a few bugs. > When the stylus comes in-prox, the pointer jumps to (0,0) (the upper > left of the screen) for a fraction of a second (even if I don't > explicitly reset all values to 0 when going out-prox). When the mouse > puck comes in-prox, the mouse pointer jumps to the lower right of the > screen (and stays there, because the mouse acts with relative > displacements). > > When the mouse comes in-prox after the stylus, the pointer is only > affected by the movement of the stylus. > When the stylus comes in-prox after the mouse, the pointer 'freezes' > and won't respond to movement until one of the devices leaves > proximity. > > I couldn't find an obvious bug by going over the code (quickly). Is > this behaviour due to X not knowing the concept of two concurrent > pointing devices, or is there something wrong with my implementation? > (not that unlikely ;-)). > > I'd still like to know that the expected behaviour should be when the > two channels are working properly, is there any way to test or verify > this? What should be the exact events that I'm getting (eg captured > with evtest or similar)? >
I don't have a protocol 5 device myself so can't send any captures; but I do know how they are supposed to work. I found your github repo and quickly glanced at it. I'll add some comments about it below. > > I also have a small question, just to be sure I'm doing it right: > >> A tablet declaring ABS_MISC support+tablet ID >> together is what xf86-input-wacom uses to detect its a protocol 5 >> device (multi-tool in proximity feature). > > Just to be sure: with "declaring tabled ID", you mean MSC_SERIAL > events (with the serial number as received by the hardware), correct? It would have been technically more accurate if I would have said "product id". tablet_id is a name used internal to xf86-input-wacom. In your code I see this: input_dev->id.vendor = SERIO_WACOM_V; input_dev->id.product = serio->id.extra; Those vendor and product ID's are what xf86-input-wacom use to enable protocol 5 device support. If it doesn't see values it knows about then it will default to Protocol 4 and I can see how that could lead to cursor jumping around. You'll want to use USB ID's to work out of the box with xf86-input-wacom. vendor=0x56a and product ID depends on tablet model. Looks like Intuos1 use a product ID of 0x20 to 0x24 depending on size. Intuos2 are 0x41 to 0x47. You can look at wacom_wac.c for exact list and find values based on your tablets MAX X/Y values. I guess that means you can't set the correct product ID until after you get a response to MAX_COORDINATES. If for some reason there is not an exact match then we'll need to use those custom SERIO_WACOM and MODEL_* values like your doing above and we will need to update xf86-input-wacom as well to understand these ID's (see wcmUSB.c in xf86-input-wacom and its table of product ID's). Maybe we want to do that anyways in the final driver code so user land knows its a serial device vs. a USB device... but as a quick test, hard coding those values should verify this is the problem. > > > Lastly, for what it's worth, I'm running a 2.6.39.2 kernel with a > 1.10.2 xorg server and xf86-input-wacom 0.11.0. Good to know. There aren't any cursor issues I know about in these recent versions. Chris > > > Roald > ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
