On Sun, Jan 24, 2010 at 1:08 PM, Jason Childs <obliv...@users.sourceforge.net> wrote: > On Sat, 2010-01-23 at 20:40 -0800, Ping Cheng wrote: >> 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.
You are right that channels are only in X driver. However, they are introduced to store the raw data that we receive from the kernel for each tool that comes from the same packet. This is necessary because repeated raw data (i.e., same value) would be filtered before reaching the X driver. Without keeping a record of the previous data for all active tools, we would not be able to drive the tool properly since we would miss some of the values that we need. > It's just a matter of sending sequence > of packets with a serial number to select which channel gets the data in > X, right? How can you store three sets (2 fingers and one pad) of data with only two channels? Maybe you assumed user would not touch the buttons (pad) if both fingers are on the tablet. Do you think that is a valid assumption (I am not saying this is invalid :)? >> > 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? I think the enum would be defined in one of the .h files since it would be used by a few .c files if not by all of them. Ping BTW, have you tested the .fdi file I sent you? ------------------------------------------------------------------------------ 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
