On Wed, Jan 6, 2010 at 3:38 PM, Jason Childs <[email protected]> wrote:
>>> src/2.6.27/wacom_wac.c >>> * added a debug printout of the data from the tablet >>> * added spin_lock/spin_unlock calls around static data access. >>> (note: without these major crashes happen when you have your hand >>> resting on the tablet while using the pen, since both packets are being >>> sent from the tablet simultaneously in that case). >> >> We need to turn the touch off (i.e., ignore touch data) as soon as a >> pen is in prox. Touch would only be resumed when pen is out of prox >> and a new touch is in (i.e., the finger is out and back in again if it >> was in prox). Make sure the stylusInProx and touchInProx are assigned >> the same way as in wacom_tpc_irq. I think you may have an order issue >> there. >> > > Yes. The wacom driver probes the pen and touch interfaces separately > and creates separate urb's for the Bamboo P&T. Because of this the > irq handler can occur simultaneously (or close enough) and cause a > crash when accessing the shared static variables in the irq handler. > This happens if the pen is in proximity and your hand is resting on > the tablet. Not sure why the tpc doesn't do the same? Without the > spinlocks my x86_64 quad core crashes consistently. Both tpc and Bamboo P&T are the same, protocol-wise. They both have separate interfaces for touch and pen. In tpc routine, all touch data are ignored until a new touch is in-prox again if pen was in-prox. I fear you processed touch data before pen is out or at least before a new touch is in. >>> * common->wcmCapacityDefault was used in some places rather than the >>> configurable common->wcmCapacity. >> >> wcmCapacityDefault check is to see if Capacity is supported for the >> device or not.. It is decided by the driver which end users can not >> change. So, they should stay in those two places. >> >> wcmCapacity is a variable can be changed by end users. The set >> wcmCapacityDefault to 3 below should be enough. You need to update >> wcmCapacity in wcmUSB.c based on the value of wcmCapacityDefault and >> user's input. Something like: >> >> common->wcmCapacity = xf86SetBoolOption(local->options, >> "Capacity", common->wcmCapacityDefault); >> >> >>> src/xdrv/wcmConfig.c >>> * added capacity check for tablet_id 0xd0 to 0xd3. it will set the >>> common->wcmCapacityDefault = 3 (as stated in comments for it in >>> xf86WcmAllocate). This keeps the left click from always being pressed >>> when a single finger touches the tablet. >>> src/xdrv/wcmUSB.c >>> * changed a check of common->wcmCapacityDefault to check >>> common->wcmCapacity instead. >> > > Ok, I was a bit confused on this one. I was trying to figure out why a > variable would be configurable by the end user but seemed to never be > used and the non configurable variable was always being checked. I'll > change it back to original and leave the code for the Bamboo P&T's to > set the default to 3. In fact, tackling the wcmCapacity and wcmCapacityDefault are not the proper way to deal with the single finger touch wcmTouchpadMode, which you (or we) wanted to translate into a set of Mac-like events. The proper way should be: in wcmValidateDevice.c: when a Bamboo touch device is found, set the tool to relative mode by default unless user configured it as absolute in xorg.conf or linuxwacom.fdi. Tablet PCs still want touch in absolute mode by default so you can not set touch to relative mode for all. in wcmCommon.c, inside /* process single finger events */ Check if the touch tool are in relative mode or not first since absolute mode touch tools don't need this wcmTouchpadMode. Only post cursor movement if the finger touches the tablet only once before it moves. If it touched two times within a time interval, send a mouse left click. Release the left click when finger goes out. This way, there is no need to check Capacity or whatsoever. The simpler the logic is, the better we may follow, right :)? Hope you didn't get confused too much and still take this as an enjoyable "challenge". Ping ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
