On Sat, 2010-01-23 at 20:40 -0800, Ping Cheng wrote:
> On Sat, Jan 23, 2010 at 8:56 AM, Jason Childs
> <obliv...@users.sourceforge.net> wrote:
> > Hi guys,
> >
> > I'm responding to my original post to try and minimize confusion
> > (hopefully).  Here is a resubmittal of the original 17 patches plus
> > another 6 that get the total for bamboo support to 23.
> 
> I think you've updated the original 17 patches, i.e., I need to update
> my local database, which is using your last 17 patches, with the new
> changes in the attached package.  Am I right?
> 
No just add 18-23. I didn't change the previous 17, just wanted to make
sure everyone was able to get all of them without searching through the
mailing list.

> > Touch is now at
> > 95% working by my estimation.  There is still a random cursor popping
> > when exiting a gesture that can happen.  It will also happen if you tap
> > one finger really quickly on the pad.  These occur in relative mode
> 
> Thank you for adding "priv->flags & ~ABSOLUTE_FLAG" check to
> wcmTouchpadMode.  The original one breaks absolute touch. Excellent
> job.
> 
> > obviously.  But pad now works again by using different tool serial
> > numbers mapped to each finger, and using 0xf0 serial for the pad.  I've
> 
> A questions (I am lazy tonight) for you:  in the kernel, do you get
> both pad and finger data in the same packet?  I guess so.  But I am
> not sure.

Yes, both are in the touch packet for Bamboo P&T.

> 
> > tried to make sure that adding serial number support per finger doesn't
> > break the current tpc2fg, but we may want to change that to use serial
> > numbers for each finger as well in the future.
> 
> If we go with this serial number approach, tcp2fg will definitely need
> to be updated.  My concern is if you can receive both pad and 2FGT
> data in the same packet (in the kernel), which is different from
> tpc2gf since it doesn't have pad, you would need to have three
> channels in wacom_drv.so to store them otherwise you lose one set of
> the data (let me know if you are confused).  As I mentioned above, I
> am not sure if this is the case or not.

I changed the X driver code to make sure that tpc2fg still uses channel
0 and 1 for touch data even with the same kernel packet format to the X
driver.  Only Bamboo P&T utilized individual serial numbers for finger
data.  In other words the changes to version 4 of the protocol should be
backwards compatible.  Yes I am confused, I though channels were a X
driver construct not the kernel.  It's just a matter of sending sequence
of packets with a serial number to select which channel gets the data in
X, right?

> 
> > I've also added
> > configuration items in the X driver for all of the gesture min/max
> > activations sizes and tap timeout.  This really make the gesture work
> > cleanly since the defaults were too large for my 4x5 480x320 resolution
> > tablet.
> 
> Great. I like this code. I will test it it on a 2FGT tpc to see how it
> works there. If you are interested, you can add an enum to distinguish
> different tablet models so we could get rid of those hardcoded if
> (common->tablet_id >= 0xd0 && common->tablet_id <= 0xd3), tpc, intuos,
> etc. checks.  Peter doesn't have time to work on it in the coming
> weeks. I don't have time either.  Please make a separate patch for
> this change if you have time.

Yes, I tried to change the define names to make them easier to
understand what functionality they impact.  I'm guessing the enum setup
should probably go in the wcmDeviceSpecCommonOptions function in the X
driver?

> 
> > Let me know what you think.
> 
> Your effort is greatly appreciated. Your beer is on me if you happen
> to visit PDX someday :).

Thanks, but the closest I usually get is SEA :).

> 
> > P.S. Ping, I haven't moved the id tables over yet in the kernel module
> > with these patches.  Still planning on doing that though.
> 
> Take your time. I don't think we are ready to make -10 in the next 2 weeks.
Ok
> 
> Ping


------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to