I was comparing current code to a REALLY old git tree so below is probably not exactly the issue.
On Mon, Jan 10, 2011 at 1:13 PM, Chris Bagwell <[email protected]> wrote: > I'm still only guessing here but looks like it may be this: > > I notice that wcmDevOpen() is now called two times; once during > DEVICE_INIT phase and once during DEVICE_ON. It used to only be > called during DEVICE_ON. > > During hotplug, the stack used to look something like this: > > init_touch_device > init_pad_device <--- hotpluged from above init > open_pad_device <--- calls getRanges() which gets min/max values from kernel. > open_touch_device <--- called when existing recursion caused by hotplug. > > So a subset of init items on that rely on ranges need to be delayed > until open phase so that valid ranges are ready. It looks like that > open_touch_device() logic may be being invoked before > open_pad_device() which would be a bad thing. > > So that leads us to probably needing to review patch set > dc010f3a620192e59d1349cb432cd4e6ab1ec619 > > I'll dig more later but got to give up for now. > > Chris > > On Mon, Jan 10, 2011 at 12:38 PM, Chris Bagwell <[email protected]> wrote: >> I only have remote access to tablet right now but I noticed this in >> the log file: >> >> Wacom Bamboo 2FG 4x5 Finger touch: Wacom USB Bamboo tablet maxX=0 >> maxY=0 maxZ=256 resX=100000 resY=100000 tilt=disabled >> >> I'm guessing the main issue is related to those zero values. >> >> I'll have to study this new code a little (related to PAD device >> cleanup). I'm sure the main issue is related to how Bamboo inits >> uniquely compared to other tablets. its really the 2nd tool that >> always calls getRanges() because of how hotplugging works. >> >> So in normal tablet, its the ERASER that calls getRanges(). In case >> of Bamboo touchpad, its the PAD device that is second and calls >> getRanges() and some 1 time init code. >> >> I see a few places if "if (!IsPad(priv))" thats probably getting >> confused and skipping some important init for touch related part. >> >> Chris >> >> On Mon, Jan 10, 2011 at 10:19 AM, Favux ... <[email protected]> wrote: >>> Never mind. While it's on the same usb channel as touch it would be a >>> different event, wouldn't it. >>> >>> On Mon, Jan 10, 2011 at 10:16 AM, Favux ... <[email protected]> wrote: >>>> Hi Chris, >>>> >>>> Pad was switched to absolute device. See the 12-15-10 commit "Switch >>>> the pad to forced absolute mode": >>>> http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=commit;h=ce98b0a20862291892fc7a3110e4779cd69dd5ba >>>> And the commits around it. >>>> >>>> Favux >>>> >>>> On Mon, Jan 10, 2011 at 9:39 AM, Chris Bagwell <[email protected]> >>>> wrote: >>>>> In reply to myself... oh yeah, the touchpad is a relative device. :-) >>>>> >>>>> but maybe something in this area has changed slightly and needs a look >>>>> at. I'll try to dig deeper when I have a minute. >>>>> >>>>> Chris >>>>> >>>>> On Mon, Jan 10, 2011 at 8:48 AM, Chris Bagwell <[email protected]> >>>>> wrote: >>>>>> Oh, if I do two finger touch, I'm able to get device type to change to >>>>>> 2 but I also get an additional interesting message (the last line in >>>>>> this snippet): >>>>>> >>>>>> [1084191.183] (II) /dev/input/event6 (10:wcmEvent): channel = 0 >>>>>> [1084191.183] (II) /dev/input/event6 (10:wcmEvent): c=0 i=3 t=2 s=1 >>>>>> x=9130 y=701 >>>>>> 2 b=0 p=0 rz=0 tx=0 ty=0 aw=0 rw=0 t=0 df=0 px=1 st=1084190800 cs=4 >>>>>> [1084191.183] (II) /dev/input/event6 (10:wcmFilterCoord): >>>>>> common->wcmRawSample = 4 >>>>>> [1084191.183] (II) /dev/input/event6 (10:wcmCheckSuppress): level = 2 >>>>>> return value = 2 >>>>>> [1084191.183] (II) /dev/input/event6 (10:commonDispatchDevice): device >>>>>> type = 2 >>>>>> [1084191.183] (II) /dev/input/event6 (10:commonDispatchDevice): Ignore >>>>>> non-movement relative data >>>>>> >>>>>> So perhaps touch device was set to relative mode at some point during >>>>>> init phase. >>>>>> >>>>>> Chris >>>>>> >>>>>> On Mon, Jan 10, 2011 at 8:45 AM, Chris Bagwell <[email protected]> >>>>>> wrote: >>>>>>> Something about that bi-sect doesn't make sense. Your pointing to a >>>>>>> commit that contains no code. >>>>>>> >>>>>>> I only have a few minutes with touch pad right now but tried git and >>>>>>> can also reproduce. >>>>>>> >>>>>>> The only thing that looked suspicious in log files is this: >>>>>>> >>>>>>> [1082669.808] (II) /dev/input/event6 (10:commonDispatchDevice): device >>>>>>> type = 4 >>>>>>> >>>>>>> I believe that says its detected as a cursor device? There is a case >>>>>>> statement for ABS_MT_SLOT that is supposed to set that value correctly >>>>>>> that seems not to be working now. >>>>>>> >>>>>>> Can you confirm if your using wacom-input Bamboo drivers as well? >>>>>>> This may be MT specific (I hope). >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On Mon, Jan 10, 2011 at 2:22 AM, Favux ... <[email protected]> wrote: >>>>>>>> Hi Peter, >>>>>>>> >>>>>>>> Bisection shows it is the 12-21-10 "Merge branch 'multimonitor-purge'" >>>>>>>> commit. Its snapshot xf86-input-wacom-68351da breaks touch. Although >>>>>>>> rather than slamming to the left it jitters horizontally in place over >>>>>>>> about 1.5 cm. The prior commit of the same date "Bamboo tablet does >>>>>>>> not report device_id anymore" snapshot xf86-input-wacom-2b9eb3d still >>>>>>>> has working touch. >>>>>>>> >>>>>>>> Favux >>>>>>>> >>>>>>>> On Sun, Jan 9, 2011 at 11:53 PM, Peter Hutterer >>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> can you run a bisect over the code to identify which commit broke it? >>>>>>>>> three different features got merged, multimonitor removal, the >>>>>>>>> scrollring >>>>>>>>> fixes and chris' bamboo patches. Not sure which one caused the bug. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Peter >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Gaining the trust of online customers is vital for the success of any >>>>>>>> company >>>>>>>> that requires sensitive data to be transmitted over the Web. Learn >>>>>>>> how to >>>>>>>> best implement a security strategy that keeps consumers' information >>>>>>>> secure >>>>>>>> and instills the confidence they need to proceed with transactions. >>>>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>>>> _______________________________________________ >>>>>>>> Linuxwacom-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
