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 <ch...@cnpbagwell.com> 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 ... <favux...@gmail.com> 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 ... <favux...@gmail.com> 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 <ch...@cnpbagwell.com> 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 <ch...@cnpbagwell.com> >>>> 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 <ch...@cnpbagwell.com> >>>>> 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 ... <favux...@gmail.com> 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 >>>>>>> <peter.hutte...@who-t.net> 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 >>>>>>> Linuxwacom-devel@lists.sourceforge.net >>>>>>> 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
